Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 104966 - ffmpeg/xine-lib-1.1.0-r3 dies during compile on x86 w/ GCC 4 due to PIC
Summary: ffmpeg/xine-lib-1.1.0-r3 dies during compile on x86 w/ GCC 4 due to PIC
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: media-video herd
URL:
Whiteboard:
Keywords:
: 116547 117929 118444 119716 119726 121619 (view as bug list)
Depends on:
Blocks: 117482
  Show dependency tree
 
Reported: 2005-09-05 18:19 UTC by Ryan Hill (RETIRED)
Modified: 2007-10-09 13:49 UTC (History)
16 users (show)

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


Attachments
xine-lib-1.1.0-mmx-pic-regalloc.diff (xine-lib-1.1.0-mmx-pic-regalloc.diff,1.65 KB, patch)
2005-09-07 09:34 UTC, Christophe Saout
Details | Diff
GCC4 asm fix (xine-lib-1.1.0-gcc4-asm.patch,2.03 KB, patch)
2005-09-08 10:19 UTC, Mark Loeser (RETIRED)
Details | Diff
simplified version of pic+fp mmx asm fix (xine-lib-1.1.0-pic+fp-asm-fix.diff,2.04 KB, patch)
2005-09-08 17:12 UTC, Christophe Saout
Details | Diff
simplified version of pic+fp mmx asm fix (really this time) (xine-lib-1.1.0-pic+fp-asm-fix.diff,2.06 KB, patch)
2005-09-08 17:19 UTC, Christophe Saout
Details | Diff
Alternative patch for dsputil_mmx.c (dsputil_mmx_regstarve.patch,1.48 KB, patch)
2006-01-12 11:33 UTC, Kevin F. Quinn (RETIRED)
Details | Diff
Slightly better patch for dsputil_mmx.c (ffmpeg) (ffmpeg-dsputil_mmx_regstarve-gcc4.patch,1.54 KB, patch)
2006-01-14 04:33 UTC, Kevin F. Quinn (RETIRED)
Details | Diff
Ebuild patchup for x86 (ffmpeg-ebuild.diff,1.84 KB, patch)
2006-01-14 06:12 UTC, Kevin F. Quinn (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Hill (RETIRED) gentoo-dev 2005-09-05 18:19:46 UTC
this is a spin off of bug #104189 and further details also can be found there.

in summary:

xine-lib-1.1.0-r3 fails to build on x86 machines running GCC 4.0.1.  this is due
to the patch 100_all_noextraflags.patch that was added in -r2 which removes the
upstream default of building x86 without PIC.  when the build reaches the ffmpeg
stage of the compile, it bails with this error:

i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../../.. -I../../../..
-I../../../../include -I../../../../include -I../../../../src
-I../../../../src/xine-engine -I../../../../src/xine-engine
-I../../../../src/xine-utils -I../../../../src/input -I../../../../src/input
-I../../../../lib -DSIMPLE_IDCT -DHAVE_AV_CONFIG_H -DRUNTIME_CPUDETECT
-DUSE_FASTMEMCPY -DCONFIG_RISKY -DCONFIG_DECODERS -DXINE_MPEG_ENCODER
-DCONFIG_ZLIB -DNDEBUG -D_REENTRANT -DXINE_COMPILE -O2 -march=pentium4
-fomit-frame-pointer -pipe -fno-ident -frename-registers -ffunction-sections
-mno-sse -fomit-frame-pointer -c dsputil_mmx.c  -fPIC -DPIC -o .libs/dsputil_mmx.o
h264dsp_mmx.c: In function 'h264_h_loop_filter_luma_mmx2':
dsputil_mmx.c:618: error: can't find a register in class 'GENERAL_REGS' while
reloading 'asm'
dsputil_mmx.c:618: error: can't find a register in class 'GENERAL_REGS' while
reloading 'asm'
make[5]: *** [dsputil_mmx.lo] Error 1
make[5]: Leaving directory
`/var/tmp/portage/xine-lib-1.1.0-r2/work/xine-lib-1.1.0/src/libffmpeg/libavcodec/i386'


the only solution that i can find to fix this is to build without -fPIC.  this
is what Debian and Fedora do, and what upstream recommends for x86.  on other
arches of course, -fPIC is necessary to build shared libraries.  see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=115006 for all the dirty details.

building without PIC enabled conflicts with hardened's needs, however.  see bug
#100552 for just one example of their efforts to whip xine-lib into shape.  so
this solution might not be the best, but i don't have another handy. 
considering gcc4 doesn't have a hardened flavour, i don't think it would
interfere too much if it were made conditional.

in any case, adding --disable-fpic to the build allows it to complete safely.
Comment 1 Ryan Hill (RETIRED) gentoo-dev 2005-09-05 18:20:10 UTC
Portage 2.0.51.22-r2 (default-linux/x86/2005.1, gcc-4.0.1-20050901,
glibc-2.3.5.20050722-r0, 2.6.13-ck1 i686)
=================================================================
System uname: 2.6.13-ck1 i686 Mobile Intel(R) Pentium(R) 4 CPU 3.06GHz
Gentoo Base System version 1.12.0_pre8
ccache version 2.4 [enabled]
dev-lang/python:     2.4.1-r1
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6
sys-devel/binutils:  2.16.1, 2.16.91.0.3
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=prescott -fomit-frame-pointer -pipe -mfpmath=sse -fno-ident"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=prescott -fomit-frame-pointer -pipe -mfpmath=sse -fno-ident
-fvisibility-inlines-hidden"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks sandbox sfperms"
GENTOO_MIRRORS="http://gentoo.chem.wisc.edu/gentoo/"
LDFLAGS="-Wl,-O1"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/home/dirtyepic/overlay"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X aac acpi alsa avi bash-completion berkdb bzip2 cddb cdr crypt curl
dbus divx4linux dts dvd dvdr dvdread encode exif ffmpeg firefox flac gdbm gif
gnutls gphoto2 gstreamer gtk gtk2 hal imagemagick imlib java jpeg mad mmap mmx
mng motif mp3 mpeg mpi ncurses nntp nptl nsplugin ogg oggvorbis opengl pcmcia
perl pic png python qt quicktime readline ruby sse sse2 ssl svg tcpd threads
tiff truetype usb vcd vorbis wifi win32codecs xml xml2 xv xvid zlib userland_GNU
kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LINGUAS

Comment 2 SpanKY gentoo-dev 2005-09-05 22:58:06 UTC
disabling PIC on x86 just avoids the issue
Comment 3 Diego Elio Pettenò (RETIRED) gentoo-dev 2005-09-06 02:29:47 UTC
xine-lib is maintained under amd64, so this is job for x86 arch team. 
Disabling -fPIC is a no-go. 
 
For me a GCC4 issue without solution provided is a low-priority issue 
generally, but if someone finds a solution (a part disabling -fPIC or enabling 
extra CFLAGS as it was done before the noextraflags patch that allows to avoid 
crashes here and there) I'll be happy to apply it. 
Comment 4 Ryan Hill (RETIRED) gentoo-dev 2005-09-06 16:14:29 UTC
no problem, that's what i expected.  just wanted to get this on file.
Comment 5 Mark Loeser (RETIRED) gentoo-dev 2005-09-06 22:21:25 UTC
Debian has a patch for this problem, as well as some others.  Its late though,
so I'll test it out tomorrow.  A quick look makes it seem like the ffmpeg they
are using is a bit newer.  We might only need the one asm fix.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319563
Comment 6 Christophe Saout 2005-09-07 09:34:10 UTC
Created attachment 67837 [details, diff]
xine-lib-1.1.0-mmx-pic-regalloc.diff

I've got a different, less intrusive solution. To quote myself:
--
I'm wondering if ffmpeg might be better of using the gcc mmx intrinsics, since
it might do better register allocation and scheduling, especially with this
kind of function inlining. It would also permanently solve the problems with
register allocation. Since eight different memory positions needs to be
accessible from that one big MMX block he needs to put everything he needs into
the normal index registers first since he can't put any register loads between
the asm statements. If you don't have %ebx (-fPIC) the compiler is screwed.

Well, since the code doesn't use any gcc mmx intrinsics, gcc won't touch the
mmx registers and so it should be safe to assume nobody will touch these
registers between to asm blocks, but gcc can insert new loads to index
registers.
Comment 7 Mark Loeser (RETIRED) gentoo-dev 2005-09-07 13:26:28 UTC
The change to the asm in the patch from Debian looks similar to what was done at
another point in that file.  I'll admit I know little, but here's the other
change in ffmpeg's CVS: http://tinyurl.com/ctxuv

I'm not certain which is better, but keeping it in 1 asm block instead of
breaking it up seems to make more sense.
Comment 8 Diego Elio Pettenò (RETIRED) gentoo-dev 2005-09-08 08:46:16 UTC
FWIW, xine-lib-1.1.0-r4 has an ffmpeg useflag that makes it use external 
ffmpeg, it could be useful for who wants to use gcc4. 
 
Comment 9 Mark Loeser (RETIRED) gentoo-dev 2005-09-08 09:38:04 UTC
(In reply to comment #8)
> FWIW, xine-lib-1.1.0-r4 has an ffmpeg useflag that makes it use external 
> ffmpeg, it could be useful for who wants to use gcc4. 
>  

Not going to be useful in this case, as the newer ffmpegs aren't patched for
this problem yet. (aka, we are going to need to add this patch to there as well
then)  I'll post my patch later.  I just ripped out the one portion of the
Debian patch to use, and its been working fine for me.  (Watched a bunch of
videos and DVDs last night with it)
Comment 10 Diego Elio Pettenò (RETIRED) gentoo-dev 2005-09-08 09:45:08 UTC
Luca, ffmpeg is your package, can you take a look at this, too? 
Comment 11 Mark Loeser (RETIRED) gentoo-dev 2005-09-08 10:19:26 UTC
Created attachment 67947 [details, diff]
GCC4 asm fix

Here's the patch I'm using.
Comment 12 Luca Barbato gentoo-dev 2005-09-08 13:27:29 UTC
Is the latest ffmpeg showing the same issue as the internal one?
Comment 13 Christophe Saout 2005-09-08 17:12:00 UTC
Created attachment 67980 [details, diff]
simplified version of pic+fp mmx asm fix

I really don't like the push/pop instructions there.

We should use =&r for the clobbered registers (0 and 2). gcc will then simply
reload dst and src from the stack the second time it's used which is cheaper
than the push/pop combinations.

Modified version of the above patch.
Comment 14 Christophe Saout 2005-09-08 17:19:05 UTC
Created attachment 67981 [details, diff]
simplified version of pic+fp mmx asm fix (really this time)

Sorry, got the register indexes messed up, this one is correct.
Comment 15 Mark Loeser (RETIRED) gentoo-dev 2005-09-08 21:45:44 UTC
(In reply to comment #12)
> Is the latest ffmpeg showing the same issue as the internal one?

No actually, media-video/ffmpeg-0.4.9_p20050906, merged fine for me.
Comment 16 Diego Elio Pettenò (RETIRED) gentoo-dev 2005-09-11 11:20:19 UTC
Commited. 
Comment 17 Mark Loeser (RETIRED) gentoo-dev 2005-12-23 18:05:40 UTC
We are going to need this patch
Comment 18 Mark Loeser (RETIRED) gentoo-dev 2005-12-23 18:06:01 UTC
*** Bug 116547 has been marked as a duplicate of this bug. ***
Comment 19 Diego Elio Pettenò (RETIRED) gentoo-dev 2005-12-23 18:09:12 UTC
Luca can you push this upstream? I'd rather see it handled there than locally on Gentoo, although I'm probably going to add it to the new patchset if that's needed.
Comment 20 Luca Barbato gentoo-dev 2005-12-24 04:10:01 UTC
Few notes:

gcc intrinsics for mmx are provent to produce bogus code at best.

gcc 4.0 has been proven to pessimize the x86 code in certain situations

bugs had been filled about that. Some issue could be fixed changing the code to be more gcc4 friendly but upstream is unlikely to do that right now since it could break on previous/ancient gcc versions
Comment 21 Mark Loeser (RETIRED) gentoo-dev 2005-12-24 09:48:00 UTC
(In reply to comment #20)
> Few notes:
> 
> gcc intrinsics for mmx are provent to produce bogus code at best.
> 
> gcc 4.0 has been proven to pessimize the x86 code in certain situations

Not sure what you mean here.
> 
> bugs had been filled about that. Some issue could be fixed changing the code to
> be more gcc4 friendly but upstream is unlikely to do that right now since it
> could break on previous/ancient gcc versions
> 

Well, we are going to have gcc-4 in ~arch pretty soon, so this needs to be fixed.
Comment 23 Ryan Hill (RETIRED) gentoo-dev 2005-12-24 12:47:35 UTC
and halcy0n has already pushed this up to ffmpeg.

http://sourceforge.net/tracker/index.php?func=detail&aid=1286673&group_id=16082&atid=116082

they don't seem to care.  one response to another gcc4 compile problem was essentially "make sure you also have gcc 3.4 installed". =/
Comment 24 Luca Barbato gentoo-dev 2005-12-24 13:29:06 UTC
since the current gcc4 issues are regressions, makes sense to ask for fixes for it instead of adding workarounds =/
Comment 25 Mark Loeser (RETIRED) gentoo-dev 2005-12-24 13:47:38 UTC
They are not regressions.  This is not a problem with GCC but a problem with the inline asm.
Comment 26 Ryan Hill (RETIRED) gentoo-dev 2005-12-24 15:04:03 UTC
ffmpeg-0.4.9_p20050906 and 0.4.9_p20051120 build fine with gcc 4.0/4.1, while 0.4.9_p20051216 dies.  there were no changes to dsputil_mmx.c or h264dsp_mmx.c between 11/20 and 12/16 [1][2].  are we doing something different in regards to how ffmpeg is being built, or should i start looking into other changes in that time?

[1]http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/i386/dsputil_mmx.c?cvsroot=FFMpeg
[2]http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/i386/h264dsp_mmx.c?cvsroot=FFMpeg


btw, offtopic but while it's on my mind, the -frename-registers switch added by xine-lib is a bad idea with >=gcc4 (but it's not the cause of this bug).

"-frename-registers
    Attempt to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization will most benefit processors with lots of registers. Depending on the debug information format adopted by the target, however, it can make debugging impossible, since variables will no longer stay in a 
Comment 27 Ryan Hill (RETIRED) gentoo-dev 2005-12-24 15:04:03 UTC
ffmpeg-0.4.9_p20050906 and 0.4.9_p20051120 build fine with gcc 4.0/4.1, while 0.4.9_p20051216 dies.  there were no changes to dsputil_mmx.c or h264dsp_mmx.c between 11/20 and 12/16 [1][2].  are we doing something different in regards to how ffmpeg is being built, or should i start looking into other changes in that time?

[1]http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/i386/dsputil_mmx.c?cvsroot=FFMpeg
[2]http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/ffmpeg/libavcodec/i386/h264dsp_mmx.c?cvsroot=FFMpeg


btw, offtopic but while it's on my mind, the -frename-registers switch added by xine-lib is a bad idea with >=gcc4 (but it's not the cause of this bug).

"-frename-registers
    Attempt to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization will most benefit processors with lots of registers. Depending on the debug information format adopted by the target, however, it can make debugging impossible, since variables will no longer stay in a home register.

    Not enabled by default at any level because it has known bugs."

http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Optimize-Options.html
Comment 28 Mark Loeser (RETIRED) gentoo-dev 2005-12-24 15:28:23 UTC
(In reply to comment #26)
> ffmpeg-0.4.9_p20050906 and 0.4.9_p20051120 build fine with gcc 4.0/4.1, while
> 0.4.9_p20051216 dies.  there were no changes to dsputil_mmx.c or h264dsp_mmx.c
> between 11/20 and 12/16 [1][2].  are we doing something different in regards to
> how ffmpeg is being built, or should i start looking into other changes in that
> time?

The difference is now we are forcing -fPIC and such on it.
Comment 29 Luca Barbato gentoo-dev 2005-12-25 04:08:33 UTC
tested the asm fix, doesn't work with the default cflags, upstream will reject it.
Comment 30 Luca Barbato gentoo-dev 2005-12-25 04:13:57 UTC
Update, it works, but there are other issues of the same kind
Comment 31 Mark Loeser (RETIRED) gentoo-dev 2005-12-25 17:56:11 UTC
(In reply to comment #29)
> Update, it works, but there are other issues of the same kind
> 

What issues?  Are you fixing them?
Comment 32 Jakub Moc (RETIRED) gentoo-dev 2006-01-05 13:27:42 UTC
*** Bug 117929 has been marked as a duplicate of this bug. ***
Comment 33 Alexandre Buisse (RETIRED) gentoo-dev 2006-01-09 12:21:42 UTC
*** Bug 118444 has been marked as a duplicate of this bug. ***
Comment 34 Kevin F. Quinn (RETIRED) gentoo-dev 2006-01-12 11:33:26 UTC
Created attachment 76927 [details, diff]
Alternative patch for dsputil_mmx.c

Ok; how about this.  The GENERAL_REGS error occurs because the compiler generates code to be able to refer to the four input memory operands (operands 4-7 in the original code) in the initial movd instructions.  On gcc-4 I guess this uses more registers than it did on gcc-3.  Since the first four operands aren't used after the initial four movd instructions, it's safe to split the asm at this point.  The split is into two sets of two (it's the set of four that causes the problem); I think it's clear enough.  I've looked at the generated assembly, and it seems sensible.

This is enough for xine-lib I think, although it already has the other patch.  Where ffmpeg is concerned, there are a host of other compilation failures.  Most can be worked around by specifying '-fomit-frame-pointer', but postproc still has issues (postproc isn't built during xine-lib).
Comment 35 Kevin F. Quinn (RETIRED) gentoo-dev 2006-01-14 04:33:46 UTC
Created attachment 77067 [details, diff]
Slightly better patch for dsputil_mmx.c (ffmpeg)

Splitting the four movd's into 3 and 1 instead of 2+2 saves an lea instruction so this patch is the best so far.
Comment 36 Kevin F. Quinn (RETIRED) gentoo-dev 2006-01-14 06:12:23 UTC
Created attachment 77071 [details, diff]
Ebuild patchup for x86

The static build works in all cases, so doesn't need any flag fiddling.  This patch moves the flag fiddling so that it's only done for the shared build, and only on x86.  I left the 'replace-flags -O0 -O2' in place, but moved the filtering of '-fforce-addr' and '-momit-leaf-frame-pointer' to the x86-only section, which now also appends -fomit-frame-pointer (similar to what xine-lib does).  I don't have an amd64 to test on so I don't know whether this is ok for amd64 or not.

With this, ffmpeg builds fine for me on gcc-3.4.4 and gcc-3.4.5 vanilla.  To build on gcc-4.0.2 vanilla, the dsputil_mmx.c patch is also required (for the shared build only). The dsputil_mmx.c patch does cause the code for gcc-3.4.x to   include the extra leal instruction, but this is such a tiny impact I don't think it's worth worrying about, so here I've applied the patch to the shared build regardless of gcc version.
Comment 37 Jakub Moc (RETIRED) gentoo-dev 2006-01-20 12:07:50 UTC
*** Bug 119726 has been marked as a duplicate of this bug. ***
Comment 38 Stefan Schweizer (RETIRED) gentoo-dev 2006-01-20 12:43:02 UTC
*** Bug 119716 has been marked as a duplicate of this bug. ***
Comment 39 Ryan Hill (RETIRED) gentoo-dev 2006-01-26 20:21:23 UTC
WFM
Comment 40 Luca Barbato gentoo-dev 2006-01-29 22:09:17 UTC
Patch committed
Comment 41 Jakub Moc (RETIRED) gentoo-dev 2006-02-05 00:35:21 UTC
*** Bug 121619 has been marked as a duplicate of this bug. ***
Comment 42 Kenyon Ralph 2006-09-02 16:36:48 UTC
I'm getting this problem on my stable x86 system with ffmpeg-0.4.9_p20051216 and gcc-4.1.1.  What are we supposed to do here, unmask ffmpeg?  Can a newer ffmpeg be marked stable, or can the patch work with the stable version of ffmpeg?

Portage 2.1-r2 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.16-gentoo-r9 i686)
=================================================================
System uname: 2.6.16-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz
Gentoo Base System version 1.12.4
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
ccache version 2.3 [enabled]
app-admin/eselect-compiler: [Not Present]
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.3
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O -march=pentium4 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/bind"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O -march=pentium4 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks fixpackages metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.mirrors.easynews.com/linux/gentoo http://mirror.datapipe.net/gentoo http://gentoo.osuosl.org"
LANG="en_US.utf8"
LC_ALL="en_US.utf8"
LINGUAS="en"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage"
USE="x86 X audiofile avi bash-completion berkdb bitmap-fonts bzip2 cairo cdr cli crypt curl dbus dlloader dri dvd dvdr encode exif fam ffmpeg firefox flac fortran freetype gdbm gif gnutls gpm gtk hal howl idn ipv6 isdnlog java jpeg jpeg2k kde kdeenablefinal lcms libg++ lm_sensors logrotate mad mmx mng mp3 mpeg musicbrainz ncurses nls nptl nptlonly offensive ogg opengl pam pcre pdflib perl png ppds pppd python qt3 qt4 quicktime readline reflection ruby session spell sse sse2 ssl threads tiff truetype truetype-fonts type1-fonts udev unicode usb vorbis win32codecs xml xorg xv zeroconf zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux linguas_en userland_GNU video_cards_nvidia"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 43 Jeroen Roos 2007-10-09 13:49:01 UTC
Question: this bug is RESOLVED, however GCC-4.x is still masked in hardened, referring to this bug...

/usr/portage/profiles/hardened/package.mask