For some reason pkg-config --libs{,-only-L} does not give any output if libdir in the .pc is set to /usr/lib64 example: lillen ~ # ls -l /usr/lib64/libffi.so lrwxrwxrwx 1 root root 16 14 feb 19.21 /usr/lib64/libffi.so -> libffi.so.5.0.10 lillen ~ # pkg-config --libs libffi -lffi lillen ~ # sed s:lib64:lib:g -i /usr/lib64/pkgconfig/libffi.pc lillen ~ # pkg-config --libs libffi -L/usr/lib -lffi If we do not get the "-L" from pkg-config at least gobject-instrospection in portage links against wrong libffi (libffi.so.4 from the gcc subdir) which later breaks when trying to compile totem from gnome-overlay: /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libffi.so.4, needed by /usr/lib64/libgirepository-1.0.so, may conflict with libffi.so.5 Portage 2.2.0_alpha23 (hardened/linux/amd64, gcc-4.5.2, glibc-2.12.2-r0, 2.6.38-rc4+ x86_64) ================================================================= System uname: Linux-2.6.38-rc4+-x86_64-Intel-R-_Core-TM-_i7_CPU_920_@_2.67GHz-with-gentoo-2.0.1 Timestamp of tree: Mon, 14 Feb 2011 04:30:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] ccache version 3.1.4 [disabled] app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.1, 3.1.3 dev-util/ccache: 3.1.4 dev-util/cmake: 2.8.3-r1 sys-apps/baselayout: 2.0.1-r1 sys-apps/openrc: 0.7.0 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.21 sys-devel/gcc: 4.5.2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82 virtual/os-headers: 2.6.36.1 (sys-kernel/linux-headers) Repositories: gentoo gamerlay-stable x11 mozilla gnome Mine Installed sets: @system ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe -ggdb -mtune=native" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe -ggdb -mtune=native" DISTDIR="/var/portage/distfiles" FEATURES="assume-digests binpkg-logs buildpkg distlocks fixlafiles fixpackages metadata-transfer news parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict test unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox" FFLAGS="" GENTOO_MIRRORS="ftp://ftp.sunet.se/pub/os/Linux/distributions/gentoo" LANG="sv_SE.UTF-8" LC_ALL="C" LDFLAGS="-Wl,--as-needed -Wl,-O1 -Wl,--sort-common -Wl,--hash-style=gnu" LINGUAS="sv en" MAKEOPTS="-j16 -l15" PKGDIR="/var/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/portage" PORTDIR_OVERLAY="/var/overlays/layman/gamerlay /var/overlays/layman/x11 /var/overlays/layman/mozilla /var/overlays/layman/gnome /var/overlays/mine" SYNC="rsync://liten.csbnet.se/gentoo-portage" USE="X a52 aac accessibility acl acpi alsa amd64 amr amrnb amrwb applet archive asyncns autoipd avahi bash-completion bluetooth branding bzip2 cairo caps ccache cdaudio cdda cdr cleartype cli clutter connection-sharing consolekit coverart cracklib crypt cups cxx dbus device-mapper devicekit devkit dhcpcd digitalradio djvu dri dts dvd dvdr dvi eds enca encode eselect evo exif fat fbcondecor ffmpeg fftw flac fluidsynth fontconfig fuse gdbm gdm gdu gif gimp glib gmp gnome gnome-keyring gphoto2 gpm grammar graphite gsf gsm gstreamer gtk gtk3 gudev hardened hpn ical iconv iconvacl icq icu id3tag idn ieee1394 iptc ipv6 jabber jack java6 jingle jpeg jpeg2k justify kate kvm lcms libffi libnotify libsamplerate logrotate lvm lzma mad maps math matroska md mdadm midi mms mmx mmxext mng moonlight mp2 mp3 mpeg mpfr mpi msn mtp mudflap multilib musepack musicbrainz natspec nautilus ncurses network-cron networkmanager nfs nls nntp nptl nptlonly ntfs ntp nut offensive ogg openal opencore-amr opengl openmp openntpd ots pam pango parted pcre pdf perl pic pidgin playlist png policykit pppd pulseaudio python qt3support quicktime quvi raw readline rrdcgi rtmp samba schroedinger seed sensord session smp sms speex spell sse sse2 sse3 ssl ssse3 startup-notification subversion svg sysfs test tex theora thesaurus threads tiff totem truetype udev unicode upnp urandom usb userlocales v4l2 vaapi vhook videos vim-syntax vorbis webkit wmf x264 xattr xcb xcomposite xml xmp xmpp xorg xrandr xscreensaver xulrunner xv xvid xvmc zeroconf zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="sv en" NETBEANS_MODULES="cnd profiler dlight harness ide java websvccommon apisupport nb" PHP_TARGETS="php5-3" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nouveau" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
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