I am trying to build Gentoo systems that doesn't have GCC installed (for security and maintainence reasons). However too many applications depends on libstdc++ Reproducible: Always Steps to Reproduce: 1. emerge -C gcc 2. env-update Actual Results: /usr/bin/python2.2: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory Expected Results: Scanning Configuration files... Exiting: No files to work on!
We don't really want to split ebuilds up into a bunch of little ebuilds - that's unnecessary and creates a serious nightmare to manage in addition to being more painful in most situations for the end-user. Save a copy of libstdc++ and put it and symlinks in manually. emerge inject sys-devel/gcc-<version> if you don't want gcc to be pulled in as a dependency of something else.
you could also just emerge gcc and then rm the stuff you don't want cd /usr/portage/sys-devel/gcc the nice way is to ebuild gcc-blahblahb.ebuild install then cd /var/tmp/portage/gcc-blahblah/image rm the cruft you don't want need cd /usr/portage/sys-devel/gcc ebuild gcc-blahblah qmerge et voila even nicer - make a copy of the gcc ebuild into your PORTDIR_OVERLAY, and have it remove the cruft, that way on version bump, you can just diff against the latest to keep things sane
closing
I actually have some ideas for implementing this as a side-car to the gcc ebuild. My immediate plan of attack will be to write an ebuild that does this: - gcc ebuild - RDEPENDS on same major version of libstdc++ - libstdc++ ebuild - DEPENDS on gcc, copies the portions of the live filesystem as its "source" files, "installs" them into the temp tree, which then gives you the opportunity to package just those files into their own tbz2 package. This, or something with the same effect, is a critical packaging trick that will need to be adopted by other ebuilds in order to scale the distribution down into handhelds or other embedded devices. It allows the toolchain to be unmerged safely, and the libstdc++ files will remain installed because of their newer mtimes. Further, I think there is *tremendous* reason to want to remove a compiler from some systems; one of those rare cases where we are fully justified in splitting the ebuild. If this won't fly, I am very curious to understand what the problems are; otherwise, assign this bug to me, I asked the reporter to submit this bug in a thread on the gentoo-dev mailing list.
My primary concern is that I don't particularly want to split up everything in the tree. That just gets messy - you end up with a RH-ish situation where you have abc, abc-server, abc-dev, abc-xyz, abc-123... In fact, I'd be a lot happier if a USE var or something like that was used to split packages.
If you can propose a solution that uses USE flags and that doesn't cause undue work for our users (or thier computers), then I would happily endorse that. In the future, I think we will also want a USE="embedded" or somthing similar in order to strip things even further. I am *not* asking to "split up everything in the tree". At the moment, I think only this ebuild deserves this special consideration, and the USE flag may be more appropriate for creating a really reduced C compiler (or something similar). Again, a finer granularity package system will eventally be required for us to move Gentoo into the embedded realm, and I agree that (local) USE flags can be used solve the majority of cases. I just strongly feel that this is a case where we should consider a split ebuild as the Right Solution. If this still doesn't justify it, then i'm going to go re-merge the perl and libperl ebuilds, because that situation is a lot less clear cut than this one. ;)
> If this still doesn't justify it, then i'm going to go re-merge the perl and > libperl ebuilds, because that situation is a lot less clear cut than this > one. ;) No, you won't. As for having libstdc++ seperate ... it might be a good thing (tm) to do, although I think the better idea will be to split off all the libs (stdc++, g2c,objc..). It should also make compile upgrades less of a pain in the butt, as they will then be SLOT'd, and old things can depend on them until they are rebuild with the new gcc. I'll have a look, and get back about this at some stage.
I am just wondering what the status is on this bug. Any ideas how to solve this?
This ebuild is sorta resolved. We don;t quite have all the atoms to keep parts of gcc (gcc-core, gcc-g77, gcc-java, and most importantly libgcc ) install yet but lv is working on a toolchain eclass which should simplify that. But as of >=gcc-3.4 libstd++ is it's own ebuild.
sort of bot not really libstdc++-v3 needs to become libstdc++ with its own SLOTing
it's been libstdc++-v3 since it was integrated into gcc 3.0... i dont really see a problem unless you want to start adding the old crap used with gcc 2.95. i dont think many of the binaries included in lib-compat compile anymore... the current ebuilds are slotted to "3.3.3", which is kinda silly when i think about it. 3.2.3->3.3.4 all include .so.5, so i should have slotted it to "5". gcc 3.4 provides .so.6, so if an ebuild for that is included it should be slotted to "6". ...does it make sense to change a slot after an ebuild has already been in the tree?
this is almost but not really fixed... so... later
