Summary: | sys-devel/gcc-4.5.2 installs libffi despite of package.use.mask'd and disabled (-libffi) USE flag | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Xake <kanelxake> |
Component: | New packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | dev-portage, grafi, ssuominen, wolf31o2 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
libffi-noinstall.patch
toolchain.eclass.libffi.diff |
Description
Xake
2011-02-14 18:51:20 UTC
USE="libffi" for sys-devel/gcc is masked for a reason, it shouldn't be used. And this looks like normal behavior for pkg-config to supress the default ABI libdir since it'll be in linkers scope anyway. (In reply to comment #1) > USE="libffi" for sys-devel/gcc is masked for a reason, it shouldn't be used. > Heh, yeah it is masked: [ebuild R ] sys-devel/gcc-4.5.2 USE="gcj graphite gtk hardened mudflap (multilib) nls nptl openmp test (-altivec) -bootstrap -build -doc (-fixed-point) -fortran (-libffi) -lto -multislot (-n32) (-n64) -nocxx -nopie -nossp -objc -objc++ -objc-gc -vanilla" 66,250 kB However: $ qlist sys-devel/gcc | grep libffi /usr/lib/debug/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32/libffi.so.4.0.1.debug /usr/lib/debug/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libffi.so.4.0.1.debug /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32/libffi.a /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32/libffi.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32/libffi.so.4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32/libffi.so.4.0.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libffi.a /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libffi.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libffi.so.4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libffi.so.4.0.1 /usr/share/doc/gcc-4.5.2/testsuite/libffi.log.bz2 /usr/share/doc/gcc-4.5.2/testsuite/libffi.sum.bz2 So that mask does not much good... > And this looks like normal behavior for pkg-config to supress the default ABI > libdir since it'll be in linkers scope anyway. > Well, this breaks things for me. On my system if I regularly build libffi and gobject-introspection I get the following: $ ldd /usr/lib64/libgirepository-1.0.so | grep ffi libffi.so.4 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libffi.so.4 (0x00007f58a571b000) However if I do the above mentioned sed and then rebuilds gobject-introspection, I get the following linkage: $ ldd /usr/lib64/libgirepository-1.0.so | grep ffi libffi.so.5 => /usr/lib/libffi.so.5 (0x00007f3e471f1000) So it seems I have more then one issue: 1. gcc builds libffi even when USE=-libffi 2. pkg-config supress the default libdir 3. ld somewhere borkes up when the two above collides So where should we go from here? Feels a bit like just fixing 1 may mask other issues wrt 3 and preserved libraries in the future. *** This bug has been marked as a duplicate of bug 289180 *** erm, reopen. if you re-emerge sys-devel/gcc with (-libffi) the libffi still gets installed? that'd be a major bug in toolchain eclasses then... (In reply to comment #4) > erm, reopen. if you re-emerge sys-devel/gcc with (-libffi) the libffi still > gets installed? > > that'd be a major bug in toolchain eclasses then... > I can rebuild gcc to try, but for how long has that flag been masked for gcc? Because my guess is that is exactly how long ago that was the last time I may have had libffi built from gcc, since I cannot recall ever had that flag unmasked... Confirm. # emerge -1av --jobs 10 gcc && qlist sys-devel/gcc | grep libffi These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-devel/gcc-4.5.2 USE="gcj graphite gtk hardened mudflap (multilib) nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -fortran (-libffi) -lto -multislot (-n32) (-n64) -nocxx -nopie -nossp -objc -objc++ -objc-gc -test* -vanilla" 66,250 kB Total: 1 package (1 reinstall), Size of downloads: 66,250 kB Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Emerging (1 of 1) sys-devel/gcc-4.5.2 >>> Installing (1 of 1) sys-devel/gcc-4.5.2 >>> Jobs: 1 of 1 complete Load avg: 1.07, 4.67, 5.55 >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * Regenerating GNU info directory index... * Processed 8 info files. /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libffi.a /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libffi.la /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libffi.so.4.0.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libffi.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libffi.so.4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32/libffi.a /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32/libffi.la /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32/libffi.so.4.0.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32/libffi.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32/libffi.so.4 /usr/lib/debug/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libffi.so.4.0.1.debug /usr/lib/debug/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/32/libffi.so.4.0.1.debug The culprit seems to be USE="gcj", seems like if you have it, then gcc compiles with libffi and installs it no matter what other USE-flags you have. (In reply to comment #5) > (In reply to comment #4) > > erm, reopen. if you re-emerge sys-devel/gcc with (-libffi) the libffi still > > gets installed? > > > > that'd be a major bug in toolchain eclasses then... > > > > I can rebuild gcc to try, but for how long has that flag been masked for gcc? > Because my guess is that is exactly how long ago that was the last time I may > have had libffi built from gcc, since I cannot recall ever had that flag > unmasked... libffi shouldn't have been installed from gcc since 14 Oct 2009 when I masked the USE flag in base/package.use.mask to avoid this mess. dev-libs/libffi is the maintained copy and with active upstream. I would support removing the USE flag from gcc entirely, and any code the eclasses have for it. (In reply to comment #8) > I would support removing the USE flag from gcc entirely, and any code the > eclasses have for it. > As I pointed out that would not change a thing. USE="gcj" enables target-libffi in gcc-4.5.2/configure, so what needs to change here AFAICS is a change to GCCs build system making it possible to build gcj against system-libffi. gcj and Go will cause libffi to be installed and both require the bundled versions afaik. (In reply to comment #10) > gcj and Go will cause libffi to be installed and both require the bundled > versions afaik. > can the gcc-libffi be statically linked into go and gcj? renamed? moved out of linkers scope? gcc-libffi and libffi syncs every few months, so I guess there's too much room for error to link unbundled copies. forcing linking against system libffi isnt an option. i'm not about to waste time trying to make older versions of gcc build against newer libffi. forcing the local libffi to only build statically and avoid installing sounds about the only thing we can do ... (In reply to comment #12) > forcing linking against system libffi isnt an option. i'm not about to waste > time trying to make older versions of gcc build against newer libffi. forcing > the local libffi to only build statically and avoid installing sounds about the > only thing we can do ... > I see your point. Another question we might ask is if even if we build libffi, do we really need to merge it? Currently during a gcj-build both libjvm and libffi is built (the former needs the latter). But at least on my system no files merged with sys-devel/gcc actually seems (at least according to ldd) to link against libffi, and libjvm is not even installed. So maybe "just" a install-mask is sufficient? After looking around some more it seems that there are more libraries that USE="gcj" installs that nothing merged with sys-devel/gcc seems to link against, but is provided also by other ebuilds, like for example libjavamath.so (gnu-classpath) so something may need reworking wrt their buildsystem and what it does install? (In reply to comment #13) > actually seems (at least according to ldd) to link against libffi, and libjvm > is not even installed. I was wrong here, looked in the wrong dir. On my system both gcj and icedtea merges libjvm. But nothing merged with sys-devel/gcj seems to link against that either. And to be honest everything in /usr/lib64/gcj-*/ seems to be duplicated by gnu-classpath, except libjvm that duplicates by icedtea here (or should be by any jre/jdk IIRC). So what is provided by USE="gcj" except the command gcj that is not already provided by other packages? i was able to build gcj with --without-libffi. libgo fails but that can be fixed easily enough. give it a try. http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02336.html It sounds like gcj --without-libffi isn't very useful. Created attachment 303291 [details, diff]
libffi-noinstall.patch
Created attachment 303305 [details, diff]
toolchain.eclass.libffi.diff
On second thought let's do it in the eclass. I also dropped all the libffi-related code. Is there a reason to keep any of it around?
Comment on attachment 303305 [details, diff]
toolchain.eclass.libffi.diff
looks nice to me
Applied. After this commit we don't have USE=libffi on gcc anymore. Samuli, can you get rid of the profile cruft? http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/toolchain.eclass?r1=1.519&r2=1.520 (In reply to comment #21) > Applied. After this commit we don't have USE=libffi on gcc anymore. > Samuli, can you get rid of the profile cruft? > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/toolchain.eclass?r1=1. > 519&r2=1.520 ebuild R #] sys-devel/gcc-4.6.2 USE="cxx fortran gtk mudflap (multilib) nls nptl objc openmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -go -graphite (-hardened) (-libffi) (-libssp) -multislot -nocxx -nopie -nossp -objc++ -objc-gc -test -vanilla" 97 kB With `cvs up` in sys-devel/gcc and eclass directories the USE flag is not disappearing with portage-2.2.0_alpha89 Now if I remove the mask from base/package.use.mask I see: [ebuild R #] sys-devel/gcc-4.6.2 USE="cxx fortran gtk libffi* mudflap (multilib) nls nptl objc openmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -go -graphite (-hardened) (-libssp) -multislot -nocxx -nopie -nossp -objc++ -objc-gc -test -vanilla" 97 kB And no, I don't have any overlays and only one correct PORTDIR dev-portage: I suppose we can't remove the mask due to the limitation of PM to refresh itself? (In reply to comment #22) > Now if I remove the mask from base/package.use.mask I see: > > [ebuild R #] sys-devel/gcc-4.6.2 USE="cxx fortran gtk libffi* mudflap > (multilib) nls nptl objc openmp (-altivec) -bootstrap -build -doc > (-fixed-point) -gcj -go -graphite (-hardened) (-libssp) -multislot -nocxx > -nopie -nossp -objc++ -objc-gc -test -vanilla" 97 kB > > And no, I don't have any overlays and only one correct PORTDIR > > dev-portage: I suppose we can't remove the mask due to the limitation of PM > to refresh itself? Looks like a cache validation problem. This is not supposed to happen under normal circumstances. Could it be that you have a stale cache entry in $PORTDIR/metadata/cache/sys-devel/gcc-4.6.2? If so, it's a known limitation of the cache format with respect to eclass changes, as discussed in this thread: http://archives.gentoo.org/gentoo-dev/msg_cfa80e33ee5fa6f854120ddfb9b468b3.xml (In reply to comment #23) > (In reply to comment #22) > > Now if I remove the mask from base/package.use.mask I see: > > > > [ebuild R #] sys-devel/gcc-4.6.2 USE="cxx fortran gtk libffi* mudflap > > (multilib) nls nptl objc openmp (-altivec) -bootstrap -build -doc > > (-fixed-point) -gcj -go -graphite (-hardened) (-libssp) -multislot -nocxx > > -nopie -nossp -objc++ -objc-gc -test -vanilla" 97 kB > > > > And no, I don't have any overlays and only one correct PORTDIR > > > > dev-portage: I suppose we can't remove the mask due to the limitation of PM > > to refresh itself? > > Looks like a cache validation problem. This is not supposed to happen under > normal circumstances. Could it be that you have a stale cache entry in > $PORTDIR/metadata/cache/sys-devel/gcc-4.6.2? If so, it's a known limitation > of the cache format with respect to eclass changes, as discussed in this > thread: > > http://archives.gentoo.org/gentoo-dev/msg_cfa80e33ee5fa6f854120ddfb9b468b3. > xml You are right. It was stale cache and `egencache --update` solved it. I'm afraid unmasking this will shoot someone in the face, but oh well... (In reply to comment #24) > You are right. It was stale cache and `egencache --update` solved it. > > I'm afraid unmasking this will shoot someone in the face, but oh well... A possible fix is to configure egencache to generate the newer md5dict format: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a058baf9ed238a1f260b6739ba7fc10c6472f6ee |