Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 354903 - sys-devel/gcc-4.5.2 installs libffi despite of package.use.mask'd and disabled (-libffi) USE flag
Summary: sys-devel/gcc-4.5.2 installs libffi despite of package.use.mask'd and disable...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-14 18:51 UTC by Xake
Modified: 2012-03-03 07:50 UTC (History)
4 users (show)

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


Attachments
libffi-noinstall.patch (libffi-noinstall.patch,896 bytes, patch)
2012-02-26 09:19 UTC, Ryan Hill (RETIRED)
Details | Diff
toolchain.eclass.libffi.diff (toolchain.eclass.libffi.diff,2.32 KB, patch)
2012-02-26 10:55 UTC, Ryan Hill (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Xake 2011-02-14 18:51:20 UTC
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
Comment 1 Samuli Suominen (RETIRED) gentoo-dev 2011-02-14 19:06:29 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.
Comment 2 Xake 2011-02-14 19:45:38 UTC
(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.
Comment 3 Samuli Suominen (RETIRED) gentoo-dev 2011-02-15 10:21:13 UTC

*** This bug has been marked as a duplicate of bug 289180 ***
Comment 4 Samuli Suominen (RETIRED) gentoo-dev 2011-02-15 10:23:38 UTC
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...
Comment 5 Xake 2011-02-15 10:32:36 UTC
(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...
Comment 6 Xake 2011-02-15 11:07:41 UTC
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
Comment 7 Xake 2011-02-15 11:39:11 UTC
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.
Comment 8 Samuli Suominen (RETIRED) gentoo-dev 2011-02-15 15:53:36 UTC
(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.
Comment 9 Xake 2011-02-15 20:32:20 UTC
(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.

Comment 10 Ryan Hill (RETIRED) gentoo-dev 2011-02-16 02:47:52 UTC
gcj and Go will cause libffi to be installed and both require the bundled versions afaik.
Comment 11 Samuli Suominen (RETIRED) gentoo-dev 2011-02-16 05:37:54 UTC
(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.
Comment 12 SpanKY gentoo-dev 2011-02-17 05:32:17 UTC
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 ...
Comment 13 Xake 2011-02-17 10:42:45 UTC
(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?
Comment 14 Xake 2011-02-17 10:59:52 UTC
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?
Comment 15 Xake 2011-02-17 11:08:57 UTC
(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?
Comment 16 Ryan Hill (RETIRED) gentoo-dev 2011-02-19 02:24:52 UTC
i was able to build gcj with --without-libffi.  libgo fails but that can be fixed easily enough.  give it a try.
Comment 17 Ryan Hill (RETIRED) gentoo-dev 2011-07-03 19:24:03 UTC
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02336.html

It sounds like gcj --without-libffi isn't very useful.
Comment 18 Ryan Hill (RETIRED) gentoo-dev 2012-02-26 09:19:00 UTC
Created attachment 303291 [details, diff]
libffi-noinstall.patch
Comment 19 Ryan Hill (RETIRED) gentoo-dev 2012-02-26 10:55:26 UTC
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 20 SpanKY gentoo-dev 2012-03-01 21:40:16 UTC
Comment on attachment 303305 [details, diff]
toolchain.eclass.libffi.diff

looks nice to me
Comment 21 Ryan Hill (RETIRED) gentoo-dev 2012-03-03 02:31:28 UTC
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
Comment 22 Samuli Suominen (RETIRED) gentoo-dev 2012-03-03 06:51:59 UTC
(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?
Comment 23 Zac Medico gentoo-dev 2012-03-03 07:05:15 UTC
(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
Comment 24 Samuli Suominen (RETIRED) gentoo-dev 2012-03-03 07:26:29 UTC
(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...
Comment 25 Zac Medico gentoo-dev 2012-03-03 07:50:32 UTC
(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