Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 812938 - sys-devel/gcc: allow building just libgcc, libstdc++ (or split into new packages)
Summary: sys-devel/gcc: allow building just libgcc, libstdc++ (or split into new packa...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords: PullRequest
Depends on:
Blocks:
 
Reported: 2021-09-13 09:30 UTC by hoelbezier
Modified: 2022-05-30 15:30 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description hoelbezier 2021-09-13 09:30:48 UTC
dev-libs/icu-69.1 is linked to libstdc++.so.6.

However, it has no RDEPEND to sys-devel/gcc nor to sys-libs/libcxx which provide for it.

Ideally it should depend on any one of them, so that users can choose which provider for libstdc++.so.6 they want to use.
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-09-14 05:11:28 UTC
It needs *a* C++ compiler, not necessarily gcc's g++. You can even mix and match Clang and libstdc++. ICU does not specifically need libstdc++ (as far as I know), it needs an implementation of the C++ standard library.

If you want to use libcxx (LLVM's project), you need to set that in your *FLAGS (CXXFLAGS and LDFLAGS(?)). It's not for USE flags or dependencies to control. clang even has a default-libcxx flag if you want to use that.

Adding a dependency in the ebuild wouldn't change any of this, it'd just force e.g. Clang to be installed?

TL;DR: You control this via *FLAGS, there's no need for an explicit dependency, and we try to avoid using USE flags for just flag changes.
Comment 2 hoelbezier 2021-09-14 13:46:23 UTC
Without setting a proper dependency in the ebuild however, installing a binary package of icu into a chroot using emerge --root= option, or downloading binary packages using --getbinpkgonly from a set up binary package server, will fail to install icu runtime dependency.

Hence, when executing a program depending on icu, I get a “cannot open shared object file” error. For example, with `newaliases` from mail-mta/postfix with USE-flag eai enabled:

newaliases: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
Comment 3 Ionen Wolkens gentoo-dev 2021-09-14 17:00:03 UTC
Packages don't typically depend on a libc either because it's supposed to always be there.

And, just like glibc, gcc is in @system set and it's not normal if you're missing it.
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-09-15 00:43:13 UTC
(In reply to Ionen Wolkens from comment #3)
> Packages don't typically depend on a libc either because it's supposed to
> always be there.
> 
> And, just like glibc, gcc is in @system set and it's not normal if you're
> missing it.

Agreed. But there is a valid use case for a container with just libstdc++. Let's repurpose this bug for a request to separately package libgcc and libstdc++ (or via USE flags on sys-devel/gcc).
Comment 5 unhappy-ending 2021-10-30 06:29:46 UTC
Actually, it would be very nice to have the gcc runtime and libstdc++ as separate packages. It would allow testing with Clang and on top of that, setting different flags for each library. From my personal testing, Clang, LLVM, libc++, libc++abi, and libunwind all fail or pass tests with different flags enabled, one size doesn't fit all. With GCC, we're kind of stuck and it isn't as flexible as it could be.
Comment 6 unhappy-ending 2022-05-24 06:40:03 UTC
ping, any update on this?
Comment 7 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-05-25 00:18:55 UTC
(In reply to unhappy-ending from comment #6)
> ping, any update on this?

xandris started a PR for it. I still haven't had any time to play with this or work on it. It's still not a priority and it's important to do the split right.

Help welcome in testing the split and ideally not doing it with seds which feel likely to break. Not a criticism of xandris' work at all though because I suggested this route as a start. She's done good work on this and the blocker is me (or someone else on toolchain@, or someone else with more time! User help welcome!) to test it, figure out what the problems are, and go from there.

I'm more willing to consider this in an experimental stage if it were somehow just for cross / ROOT building, and not for "normal" systems, but we'd need some way to do that too.

So, a few things:
1. Ideally try to find some way to do this by minimising the # of seds;
2. If possible, make patches to do 1. and upstream some of them;
3. Spitball about how we can easily expose this for ROOT= stuff without unleashing it on normal users.
4. Consider either building full GCC and only installing a subset for now, or make a minimal effort attempt to just reduce the build without a fully minimal set of ebuilds (e.g. disable bootstrapping, additional language features, etc, but don't go all-out with only building *EXACTLY* the needed targets and subdirs).

It's missing from this bug but from the discussion xandris and I had on IRC, it's worth noting Exherbo do split it out. I don't know if any other from-source distros do.

I'm most tempted by 4, tbh. Because then we can easily evaluate if it's worth the fragility (or not) and risks of refining it further.
Comment 8 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-05-25 00:21:30 UTC
(In reply to unhappy-ending from comment #5)
> Actually, it would be very nice to have the gcc runtime and libstdc++ as
> separate packages. It would allow testing with Clang and on top of that,
> setting different flags for each library. From my personal testing, Clang,
> LLVM, libc++, libc++abi, and libunwind all fail or pass tests with different
> flags enabled, one size doesn't fit all. With GCC, we're kind of stuck and
> it isn't as flexible as it could be.

The key difference being that LLVM makes it easy (although we've had issues, we've worked it out with the LLVM folks) to do the split.

It'd also be useful to know (in another bug) exactly what those issues you've hit have been.

(In reply to unhappy-ending from comment #6)
> ping, any update on this?

In general, updates would be posted to the bug already. The best thing you can do is help and I've outlined how above.
Comment 9 unhappy-ending 2022-05-26 08:22:31 UTC
(In reply to Sam James from comment #8)
> It'd also be useful to know (in another bug) exactly what those issues
> you've hit have been.

Errors using non-standard CFLAGS like -ffast-math, -fwhole-program-vtables, etc. Example: I can't build clang with -fwhole-program-vtables but I can libc++, if they were bundled together then libc++ couldn't get the extra rice. I don't think a bug report is proper since if I break it with a non-standard flag it's my fault?

(In reply to Sam James from comment #7)
> Help welcome in testing the split and ideally not doing it with seds which
> feel likely to break. Not a criticism of xandris' work at all though because
> I suggested this route as a start. She's done good work on this and the
> blocker is me (or someone else on toolchain@, or someone else with more
> time! User help welcome!) to test it, figure out what the problems are, and
> go from there.
> 
> I'm more willing to consider this in an experimental stage if it were
> somehow just for cross / ROOT building, and not for "normal" systems, but
> we'd need some way to do that too.

I checked out the pull request. How do I download the files to test the ebuilds?

FWIW, I'm not doing any crossdev or ROOT building stuff, I'm on a "normal" system that's built by Clang and the LLVM toolchain, using compiler-rt, llvm-libunwind, and libc++. A few packages do not like compiler-rt or libc++ and have to resort to libstdc++ and libgcc so it would be interesting in the event you could build a GNU system without GCC, but still having libstdc++ and libgcc for the programs that need it. Slowly, work is being done to build glibc with Clang & friends and that would leave libstdc++ and libgcc for the stuff that doesn't play well with LLVM's alternatives.
Comment 10 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-05-27 22:55:40 UTC
(In reply to unhappy-ending from comment #9)
> (In reply to Sam James from comment #8)
> > It'd also be useful to know (in another bug) exactly what those issues
> > you've hit have been.
> 
> Errors using non-standard CFLAGS like -ffast-math, -fwhole-program-vtables,
> etc. Example: I can't build clang with -fwhole-program-vtables but I can
> libc++, if they were bundled together then libc++ couldn't get the extra
> rice. I don't think a bug report is proper since if I break it with a
> non-standard flag it's my fault?
> 
> (In reply to Sam James from comment #7)
> > Help welcome in testing the split and ideally not doing it with seds which
> > feel likely to break. Not a criticism of xandris' work at all though because
> > I suggested this route as a start. She's done good work on this and the
> > blocker is me (or someone else on toolchain@, or someone else with more
> > time! User help welcome!) to test it, figure out what the problems are, and
> > go from there.
> > 
> > I'm more willing to consider this in an experimental stage if it were
> > somehow just for cross / ROOT building, and not for "normal" systems, but
> > we'd need some way to do that too.
> 
> I checked out the pull request. How do I download the files to test the
> ebuilds?
> 

Append .patch to the URL (this works for github commits too, but you can do it for a PR as well): https://github.com/gentoo/gentoo/pull/23188.patch.

> FWIW, I'm not doing any crossdev or ROOT building stuff, I'm on a "normal"
> system that's built by Clang and the LLVM toolchain, using compiler-rt,
> llvm-libunwind, and libc++. A few packages do not like compiler-rt or libc++
> and have to resort to libstdc++ and libgcc so it would be interesting in the
> event you could build a GNU system without GCC, but still having libstdc++
> and libgcc for the programs that need it. Slowly, work is being done to
> build glibc with Clang & friends and that would leave libstdc++ and libgcc
> for the stuff that doesn't play well with LLVM's alternatives.

I'm sorry, I'd forgot about that case, it'd come up before but I'd forgot about it in my summary. Needing e.g. libstdc++ (and I guess libgcc, although unusual, guess it's worth it for the same ABI issues as libstdc++ vs libc++) with Clang is a valid case, of course.

A good start is probably just having gcc with forced on flags for libstdc++, libgcc only builds, as a very safe first step. I don't know if we'll do this via "libstdc++-only" or similar (I don't generally like "negative" flags) or via adding a flag for C, ..., and having people turn them all off but a few if e.g. doing Clang.