having sys-devel/gcc-7.2.0-r1 installed and in use currently no other compiler installed sys-devel/gcc-6.4.0-r1 fails to compile attached: build.log and emerge --info output Reproducible: Always
Created attachment 515038 [details] build.log.xz
Created attachment 515040 [details] emerge --info output
My situation: sys-devel/gcc-6.4.0 to be updated to sys-devel/gcc-6.4.0-r1 And this segfault every time... # gcc-config -l [1] x86_64-pc-linux-gnu-6.4.0 [2] x86_64-pc-linux-gnu-7.2.0 * For me the culprit was an error printed immediately before or after the segfault (now I cannot remember...): version `CXXABI_1.3.11' not found (required by /usr/lib/llvm/5/lib64/../lib64/libLLVMSupport.so.5) So I switched to x86_64-pc-linux-gnu-6.4.0, then: emerge -1q =sys-devel/llvm-5.0.1 emerge -1q =sys-devel/gcc-6.4.0-r1 sys-devel/gcc-6.4.0-r1 was compiled and installed successfully. Then switched back to gcc-7.2 and rebuilt llvm-5.0.1
I have seen this too, but unfortunately, I don't have some older gcc around anymore...
If you have the same error you can try to temporary uninstall sys-devel/llvm-5, then compile sys-devel/gcc-6.4.0 hoping for the best. This is what I'll try, and I suppose that at worst you'll have to reinstall llvm.
I think it's unexpected to see llvm being used when CC/CXX/AR is not overridden to point to llvm tools: > /usr/x86_64-pc-linux-gnu/bin/ar: /var/tmp/portage/sys-devel/gcc-6.4.0-r1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /usr/lib/llvm/5/lib64/../lib64/libLLVMSupport.so.5) > ../libtool: line 1132: 8323 Segmentation fault /usr/x86_64-pc-linux-gnu/bin/ar rc .libs/libstdc++.a ... My guess is that your ar tool is loading llvm's libstdc++.so (or is linked against it?). When gcc-6.4.0 is being built it also builds (older) libstdc++.so and maybe overrides new library path via LD_LIBRARY_PATH. Older libstdc++.so is being used by ar and ar crashes. LD_LIBRARY_PATH is likely injected by libtool. Can you reproduce failure? Go the gcc build directory and run the command it fails on: $ /bin/bash ../libtool --tag CXX --mode=link ... -o libstdc++.la ... If it does fail try to strace it (prepend 'strace -f -o/tmp/log -y') and we'll see where it gets the libstdc++ from: $ strace -f -o/tmp/log -y /bin/bash ../libtool --tag CXX --mode=link ... Attach /tmp/log syscall trace.
running 'sudo -u portage /bin/bash ../libtool --tag CXX --mode=link /var/tmp/portage/sys-devel/gcc-6.4.0-r1/work/build/./gcc/xgcc -shared-libgcc -B/var/tmp/portage/sys-devel/gcc-6.4.0-r1/work/build/./gcc -nostdinc++ -L/var/tmp/portage/sys-devel/gcc-6.4.0-r1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/var/tmp/portage/sys-devel/gcc-6.4.0-r1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-6.4.0-r1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -L/var/tmp/portage/sys-devel/gcc-6.4.0-r1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/../libvtv/.libs -Wl,--rpath -Wl,/var/tmp/portage/sys-devel/gcc-6.4.0-r1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/../libvtv/.libs -Wl,-O1 -Wl,-z,relro -Wl,--gc-sections -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -fvtable-verify=std -Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la -o libstdc++.la -version-info 6:22:0 -Wl,--version-script=libstdc++-symbols.ver -lm -rpath /usr/lib/../lib64 compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo compatibility-c++0x.lo compatibility-atomic-c++0x.lo compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la ../src/c++11/libc++11convenience.l' from pwd '/var/tmp/portage/sys-devel/gcc-6.4.0-r1/work/build/x86_64-pc-linux-gnu/libstdc++-v3' succeeds, segfault not reproduced ar is not linked to llvm: ldd /usr/x86_64-pc-linux-gnu/binutils-bin/2.29.1/ar linux-vdso.so.1 (0x00007ffc0b3c9000) libbfd-2.29.1.so => /usr/lib64/binutils/x86_64-pc-linux-gnu/2.29.1/libbfd-2.29.1.so (0x00007fced2065000) libc.so.6 => /lib64/libc.so.6 (0x00007fced1c9b000) libz.so.1 => /lib64/libz.so.1 (0x00007fced1a84000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fced1880000) /lib64/ld-linux-x86-64.so.2 (0x00007fced25b8000
Interesting. does 'ar' SIGSEGV if you just rerun 'make'? stracing that would be a good idea as well.
Running make from within this dir is fine (I did a make clean before, so the entire dir was build) So, maybe it's related to some environment variables?
temporarily unmerge sys-devel/llvmgold, then the build succeeds.
Surprisingly, uninstalling llvm-gold makes it possible to emerge older gcc. But question for me remains: Why is llvm involved in building gcc?
I think llvm-gold drops a symlink to LTO plugin right into gcc or binutils directory. We need to find out how binutils decides to load (or not to load) that plugin.
*** Bug 648410 has been marked as a duplicate of this bug. ***
I managed to get a stackdump, but I'm gonna have to recompile a few things with debug symbols for it to be remotely useful :( Thread 1 (LWP 10702): #0 0x00007fa6f62c694b in __pthread_initialize_minimal () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fa6f62c6009 in _init () from /lib64/libpthread.so.0 No symbol table info available. #2 0x0000000000000000 in ?? () No symbol table info available. info registers rax 0x7fa6f91a49d0 140355120548304 rbx 0x5651ac675110 94908784791824 rcx 0x7fa6f62c6925 140355071404325 rdx 0x7fa6f91a46c0 140355120547520 rsi 0x7fff32a59af8 140734043101944 rdi 0x7fa6f91a4990 140355120548240 rbp 0xa2 0xa2 rsp 0x7fff32a56e80 0x7fff32a56e80 r8 0x7fa6f9af9990 140355130333584 r9 0x0 0 r10 0x7fa6f9161000 140355120271360 r11 0x246 582 r12 0x0 0 r13 0x7fff32a5a010 140734043103248 r14 0x5651ac67b000 94908784816128 r15 0x0 0 rip 0x7fa6f62c694b 0x7fa6f62c694b <__pthread_initialize_minimal+91> eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0
#0 0x00007f9de445494b in __pthread_initialize_minimal_internal () at nptl-init.c:280 280 THREAD_SETMEM (pd, cpuclock_offset, GL(dl_cpuclock_offset)); (gdb) bt full #0 0x00007f9de445494b in __pthread_initialize_minimal_internal () at nptl-init.c:280 pd = 0x7f9de73326c0 sa = {__sigaction_handler = {sa_handler = 0x4800000007, sa_sigaction = 0x4800000007}, sa_mask = {__val = { 140316165208952, 93923055013888, 140316174956384, 0, 140316174959576, 78, 1196504041701062656, 140316174889200, 0, 140732656359232, 0, 0, 0, 140316165211040, 93923055014752, 140732656359232}}, sa_flags = -416354304, sa_restorer = 0x7f9de72f0c14} static_tls_align = 140316165218720 limit = {rlim_cur = 140732656359280, rlim_max = 7} pagesz = <optimized out> minstack = <optimized out> rtld_lock_count = <optimized out> #1 0x00007f9de4454009 in _init () at ../sysdeps/x86_64/crti.S:74 No locals. #2 0x0000000000000000 in ?? ()
These backtraces are not very useful. They probably hint at already destroyed memory structures (bss?) that contain loaded libraries. Did you manage to reproduce it bu running a command from $WORKDIR?
(In reply to Sergei Trofimovich from comment #16) > These backtraces are not very useful. They probably hint at already > destroyed memory structures (bss?) that contain loaded libraries. Did you > manage to reproduce it bu running a command from $WORKDIR? Nope :(. It always succeeded in WORKDIR regardless what I tried.
*** Bug 636104 has been marked as a duplicate of this bug. ***
*** Bug 705302 has been marked as a duplicate of this bug. ***
bug #705302 revealed even better reproducer: System uses gcc:9.2.0, has llvm[z3] and llvmgold installed. llvm[z3] makes /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/LLVMgold.so to pull in z3. z3 uses latest features on libstdc++ not available in gcc:8.3.0. Attempt to build gcc:8.3.0 fails as: /usr/x86_64-pc-linux-gnu/bin/ranlib ../../.././gcc/32/libgcc_eh.a /usr/x86_64-pc-linux-gnu/bin/ranlib: /dev/shm/portage/sys-devel/gcc-8.3.0-r3/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /usr/lib64/libz3.so.4.8) (if you are lucky it also SIGSEGVs ar).
Maybe related: https://github.com/InBetweenNames/gentooLTO/issues/490#issuecomment-598032742
Yep, there's definitely an LTO problem as well. Building gcc 8.4.0 fails on my machine during src_install because it rebuilds libgcc1: libtool: compile: x86_64-pc-linux-gnu-g++ -std=gnu++98 -DHAVE_CONFIG_H -I. -I/var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1 -I /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/../include -I /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work /gcc-8.4.0/libcc1/../libgcc -I ../gcc -I/var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/../gcc -W -Wall -fvisibility=hidden -march=native -mtune=native -Wall -pipe -g3 -ggdb3 -gdwarf-4 -fno-omit-frame-pointer -O2 -MT findcomp.lo -MD -MP -MF .deps/fi ndcomp.Tpo -c /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/findcomp.cc -fPIC -DPIC -o .libs/findcomp.o make[2]: Leaving directory '/var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/build/libcc1' make[1]: Leaving directory '/var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/build' x86_64-pc-linux-gnu-g++: /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by x86_64-pc-linux-gnu-g++) I made sure that llvmgold is not around, but libLTO is... and as far as I can tell, since GCC 9.1 (toolchain, not target version), is also using LTO while actually building sys-devel/gcc packages. gcc-config creates the symlink when switching the system compiler, so there's no easy way to get rid of it - it must be manually moved out of the way temporarily.
(In reply to Mihai Moldovan from comment #22) > Yep, there's definitely an LTO problem as well. > > Building gcc 8.4.0 fails on my machine during src_install because it > rebuilds libgcc1: > > libtool: compile: x86_64-pc-linux-gnu-g++ -std=gnu++98 -DHAVE_CONFIG_H -I. > -I/var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1 -I > /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/../include -I > /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work > /gcc-8.4.0/libcc1/../libgcc -I ../gcc > -I/var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/../gcc -W > -Wall -fvisibility=hidden -march=native -mtune=native -Wall -pipe -g3 -ggdb3 > -gdwarf-4 -fno-omit-frame-pointer -O2 -MT findcomp.lo -MD -MP -MF .deps/fi > ndcomp.Tpo -c > /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/findcomp.cc > -fPIC -DPIC -o .libs/findcomp.o > > make[2]: Leaving directory > '/var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/build/libcc1' > > make[1]: Leaving directory > '/var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/build' > > x86_64-pc-linux-gnu-g++: > /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/build/x86_64-pc-linux-gnu/ > libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.26' not found > (required by x86_64-pc-linux-gnu-g++) > > I made sure that llvmgold is not around, but libLTO is... and as far as I > can tell, since GCC 9.1 (toolchain, not target version), is also using LTO > while actually building sys-devel/gcc packages. > > gcc-config creates the symlink when switching the system compiler, so > there's no easy way to get rid of it - it must be manually moved out of the > way temporarily. libLTO is a clang library. gcc-config should hot touch it. I don't see lto in your compiler flags above. My guess would be that your ld is ld.gold (say, via sys-devel/binutils[default-gold]). That pulls in libstdc++ from latest compiler and conflicts with a gcc build of older libstdc++. One way to check would be to flip ld to ld.bdf to make sure. If it works then more permanent workaround could be to use 'LDFLAGS="${LDFLAGS} -static-libstdc++"' just for binutils (say, via package.env) to avoid dynamic loading of libstdc++.
I'm barking up the wrong tree again... > libLTO is a clang library. gcc-config should hot touch it. Nomenclature issue on my end. I did mean the liblto_plugin.so library installed by sys-devel/gcc and its symlink in /usr/${CHOST}/binutils-bin/lib/bfd-plugins/, which is managed through gcc-config. > I don't see lto in your compiler flags above. My guess would be that your ld is ld.gold (say, via sys-devel/binutils[default-gold]). That pulls in libstdc++ from latest compiler and conflicts with a gcc build of older libstdc++. I use neither. I did enable the gold use flag for binutils (in case I'd ever need it), but default-gold is off. I also made sure to uninstall sys-devel/llvmgold temporarily in order to remove its plugin symlink. I even disabled the lto USE flag on gcc:9.3.0 (my current system compiler), but that did nothing useful (well, other than maybe not link-time optimize the gcc:9.3.0 binaries themselves). Whatever is happening here, it doesn't seem to be related to any binutils plugin and instead is a completely different problem. Some that I caused myself. Sorry for the noise, ignore my comment.
(In reply to Mihai Moldovan from comment #24) > Whatever is happening here, it doesn't seem to be related to any binutils > plugin and instead is a completely different problem. Do you use ccache by chance? Recent versions use symbols that changed slightly in recent gccs and thus can't work on older ones. -static-libstdc++ for ccache should workaround it as well.
I do use ccache! And it links to libstdc++! And it was recently updated to 4.1 (and previously to 4.0 from the 3.x series). That probably explains why I haven't run into this problem before - ccache's code changed quite dramatically. I use ccache with paludis, but couldn't be bothered to enable the feature with portage, so there's a difference that might explain why I couldn't reproduce it when building the package with portage. I'll try disabling ccache to see if it works. This said, I still don't understand why the newly built target package's libstdc++ would be preloaded when calling the system compiler in src_install, but maybe that's just an oddity of GCC's build system. I guess it thinks it's in stage 3 and uses itself - so must preload its own libraries, including libstdc++ - when instead, since the building happens at install time (which sounds weird to begin with, but is consistently happening all the time with both package managers), the ccache-wrapped system is used. Thanks for the massively helpful input, I totally didn't think of ccache. I'll debug this further over the holidays.
ccache-4 changed a few things: 1. it uses c++, and that pulls in libstdc++ 2. it uses multithreaded re-compression from old format to a new format. 3. it switched to cmake 4. it started using atomics and that pulled in very modern libstdc++ symbols
Hi, on my system I have gcc 11 and llvm 12 installed. I'm suffering from this bug while compiling gcc-8.5.0 that I require for some custom stuff. I tried to force ld.bfd instead of ld.gold (by forcing a symlink), removing llvmgold package but no success. ccache is not installed at all. I posted in bug #761220 my build log and emerge info, I can post it also here if useful. Does anyone has any suggestion on what to try? Many thanks.
(In reply to Fabio Coatti from comment #28) > Hi, on my system I have gcc 11 and llvm 12 installed. I'm suffering from > this bug while compiling gcc-8.5.0 that I require for some custom stuff. I > tried to force ld.bfd instead of ld.gold (by forcing a symlink), removing > llvmgold package but no success. ccache is not installed at all. > I posted in bug #761220 my build log and emerge info, I can post it also > here if useful. Does anyone has any suggestion on what to try? > > Many thanks. There you posted logs with ld.gold. Please post the build logs with ld.bfd and emerge --info.
(In reply to Sergei Trofimovich from comment #29) > (In reply to Fabio Coatti from comment #28) > > Hi, on my system I have gcc 11 and llvm 12 installed. I'm suffering from > > this bug while compiling gcc-8.5.0 that I require for some custom stuff. I > > tried to force ld.bfd instead of ld.gold (by forcing a symlink), removing > > llvmgold package but no success. ccache is not installed at all. > > I posted in bug #761220 my build log and emerge info, I can post it also > > here if useful. Does anyone has any suggestion on what to try? > > > > Many thanks. > > There you posted logs with ld.gold. Please post the build logs with ld.bfd > and emerge --info. Thanks for the comment; I of course rebuilt the same package using ld.bfd...or, better, I was sure to have done so. But your suggestion made me review all the logs of several tries and indeed it was always gold. I had to rebuild binutils with -gold USE flag in order to be sure and now gcc-8.5.0 got compiled correctly. Thanks again!
Same issue, with binutils compiled with gold support, happens with sys-devel/gcc-10.3.0-r2
(In reply to Fabio Coatti from comment #28) > Hi, on my system I have gcc 11 and llvm 12 installed. I'm suffering from > this bug while compiling gcc-8.5.0 that I require for some custom stuff. I > tried to force ld.bfd instead of ld.gold (by forcing a symlink), removing > llvmgold package but no success. ccache is not installed at all. > I posted in bug #761220 my build log and emerge info, I can post it also > here if useful. Does anyone has any suggestion on what to try? > > Many thanks. Hi, I also need to build gcc 8.5.0 on my system running on Fedora 36 and gcc 12.1.1 20220507. Unfortunately, I also bump into the same bug and I would truly appreciate it if you suggested things to try (I have already tried patches suggested elsewhere to no avail). I am attaching a log of my building process (build.log.gz), but the summary of it is: tar xvf gcc-8.5.0.tar.gz cd gcc-8.5.0/ contrib/download_prerequisites cd .. mkdir build-gcc-85 cd build-gcc-85 ../gcc-8.5.0/configure --prefix=/usr/local/gcc-85 --program-suffix=85 --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --enable-shared --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --enable-libgomp --disable-libssp --enable-libmpx --enable-vtable-verify export CFLAGS="-march=native -pipe -fstack-protector-strong -O2" export CXXFLAGS="-march=native -pipe -fstack-protector-strong -O2" export LDFLAGS="-Wl,-O1 -Wl,--as-needed -march=native -pipe -fstack-protector-strong -Wl,--as-needed -Wl,--hash-style=gnu" make . . . make[9]: Entering directory '/root/build-gcc-8.5/x86_64-pc-linux-gnu/32/libstdc++-v3/include' mkdir -p ./x86_64-pc-linux-gnu/bits/stdc++.h.gch /root/build-gcc-8.5/./gcc/xgcc -shared-libgcc -B/root/build-gcc-8.5/./gcc -nostdinc++ -L/root/build-gcc-8.5/x86_64-pc-linux-gnu/32/libstdc++-v3/src -L/root/build-gcc-8.5/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -L/root/build-gcc-8.5/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs -B/usr/local/gcc-85/x86_64-pc-linux-gnu/bin/ -B/usr/local/gcc-85/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/gcc-85/x86_64-pc-linux-gnu/include -isystem /usr/local/gcc-85/x86_64-pc-linux-gnu/sys-include -m32 -x c++-header -nostdinc++ -g -march=native -pipe -fstack-protector-strong -O2 -D_GNU_SOURCE -m32 -fvtable-verify=std -I/root/build-gcc-8.5/x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu -I/root/build-gcc-8.5/x86_64-pc-linux-gnu/32/libstdc++-v3/include -I/root/gcc-8.5.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /root/gcc-8.5.0/libstdc++-v3/include/precompiled/stdc++.h \ -o x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch /root/build-gcc-8.5/./gcc/cc1plus: /root/build-gcc-8.5/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /root/build-gcc-8.5/./gcc/cc1plus) make[9]: *** [Makefile:1765: x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1
Created attachment 790463 [details] Log of building process The building process breaks when compiling cc1plus
(In reply to Edgar from comment #32) > (In reply to Fabio Coatti from comment #28) > > Hi, on my system I have gcc 11 and llvm 12 installed. I'm suffering from > > this bug while compiling gcc-8.5.0 that I require for some custom stuff. I > > tried to force ld.bfd instead of ld.gold (by forcing a symlink), removing > > llvmgold package but no success. ccache is not installed at all. > > I posted in bug #761220 my build log and emerge info, I can post it also > > here if useful. Does anyone has any suggestion on what to try? > > > > Many thanks. > > Hi, I also need to build gcc 8.5.0 on my system running on Fedora 36 and gcc > 12.1.1 20220507. Unfortunately, I also bump into the same bug and I would > truly appreciate it if you suggested things to try (I have already tried > patches suggested elsewhere to no avail). > Hi, this is the Gentoo bug tracker, not GCC's. You should file a bug upstream with GCC. If you do, please link it here, as I'd like to know about it! Thanks.
(In reply to Edgar from comment #33) > Created attachment 790463 [details] > Log of building process > > The building process breaks when compiling cc1plus Edgar, If you go through the comments, it turns out the problem can be tracked down to the linker: whether binutils has been compiled with gold enabled and the linker used is gold or not. However I'm not sure how to deal with this under Red Hat or other distros, where you don't have an easy freedom to turn USE flags on and off.
Indeed, I think this might be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688.
Dear All, Thank you very much for your help pointing to right forum and I apologize to have posted here, but it has been really difficult to find useful information on this bug/problem.
This is fixed, really. See bug 886447 and bug 843119.
