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.
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.
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
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.
(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).
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.
ping, any update on this?
(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.
(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.
(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.
(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.
Just stumbled upon this. I am having the exact same problem as OP. Has there been some progress towards mainlining any of this? Thanks
(In reply to Mattias Merilai from comment #11) > Just stumbled upon this. I am having the exact same problem as OP. > Has there been some progress towards mainlining any of this? > Thanks No, I'm afraid. It's really something I'm interested in but it's non-trivial and I've not had time to look at xandris' work yet or play with it.
So I went and played around with this. As a background. I am building small (hardened) VMs using ROOT=. For them to be, well, small, I have dropped @system and am including only what is strictly needed. Regarding libstdc++, as a proof of concept I have so far emerged gcc and installmasked 99,9% of it. But what I cannot installmask is the forever that it takes to actually compile gcc. So hence my woot for split ebuilds, or any other mechanism that could be employed to achieve the same end. Anyway. I went and checked out the merge request. It was quite the ride and I was out of my depth for most of the time:) 1) the eclass patch no longer applies and throws like 15 failed hunks. I am nowhere near of hoping to follow everything that is going on there, so no manual merge for me either. But what I was able to do with not much effort was to rename the whole file into toolchain2.eclass, sed all of the internals to the new name and import that into the split ebuilds. I wanted to keep this experimental eclass separate from my actual system anyway, too. 2) The ebuilds could not figure out where to download the patches from. So I replaced everything gentoo_urls in my toolchain2.eclass with up-to-date stuff from toolchain.eclass. 3) The current gcc-11.3.0.ebuild has like 5 more variables in it than the 11.2.0 ebuilds in the merge request. I replaced the guts in the split ebuild with newer stuff, just in case, and bumped them to 11.3.0 to match my build environment. 4) The libstdc++ ebuild did not pull the libgcc ebuild into my ROOT. I changed the DEPEND into a RDEPEND. 5) gcc-config complains about the missing gcc-bin direcory. Seems to be just an annoyance, though. 6) libstdc++.so was not actually being produced. I tracked this down to to /^configure-target-libstdc++-v3: maybe-all-gcc$/d in case libstdc++) of src_prepare. Removing this line solved the problem. 7) the built libstdc++.so was missing _ZTINSt6thread6_StateE, maybe more. I added IUSE openmp back to it in the eclass and that took care of it. 8) I figured enabling openmp moved things around in the build, and added the maybe-all-gcc sed back into src_prepare, figuring the dev must have had some reason to put it there. And it did not cause the missing .so problem anymore, although it no longer made a difference in build time neither, which ended up being ~10 minutes for me. After this I can report that the split ebuilds compile and merge successfully. I have deployed a resulting ROOT and it runs speedtest++ as a proof of concept just fine. I am still installmasking all of the include dir, and for some reason I have to run ldconfig in the new ROOT, but I'm rather happy for now.
(In reply to Mattias Merilai from comment #13) > So I went and played around with this. > > As a background. I am building small (hardened) VMs using ROOT=. For them to > be, well, small, I have dropped @system and am including only what is > strictly needed. Regarding libstdc++, as a proof of concept I have so far > emerged gcc and installmasked 99,9% of it. But what I cannot installmask is > the forever that it takes to actually compile gcc. So hence my woot for > split ebuilds, or any other mechanism that could be employed to achieve the > same end. > Thanks for the background & also trying it out. It's valuable! > 6) libstdc++.so was not actually being produced. I tracked this down to to > /^configure-target-libstdc++-v3: maybe-all-gcc$/d in case libstdc++) of > src_prepare. Removing this line solved the problem. > [...] > 8) I figured enabling openmp moved things around in the build, and added the > maybe-all-gcc sed back into src_prepare, figuring the dev must have had some > reason to put it there. And it did not cause the missing .so problem > anymore, although it no longer made a difference in build time neither, > which ended up being ~10 minutes for me. This sort of thing is exactly why I'm nervous at the moment. There's no proper build system support for building part of GCC (or the parts we want, anyway) and I'm nervous about it silently not installing a critical component, possibly in an environment-dependent way (ideally, we'd have the split ebuilds used for everyone, not sure how realistic that is, but imagine if e.g. it turns out to break on arm and we only notice too late)/ That sort of thing stops being a concern with a proper autotools patch as opposed to seds.
(In reply to Sam James from comment #12) > (In reply to Mattias Merilai from comment #11) > > Just stumbled upon this. I am having the exact same problem as OP. > > Has there been some progress towards mainlining any of this? > > Thanks > > No, I'm afraid. It's really something I'm interested in but it's non-trivial > and I've not had time to look at xandris' work yet or play with it. FTR I'm somewhat against this split, as long as it is not supported upstream. Let's not multiply our toolchain pain...
All I actually want here is some solution for minimal ROOTs. It might be that we can just tell people to use LLVM or we can think of some other solution for GCC and friends. (Anything we do here I'd probably want to only be for the ROOT case, not "change our whole way of building gcc" because it's icky)
