Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 644772 - sys-devel/gcc: build failures when ld, ar or others use system libstdc++.so not compatible with built gcc's
Summary: sys-devel/gcc: build failures when ld, ar or others use system libstdc++.so n...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 636104 648410 705302 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-01-16 16:36 UTC by Christian
Modified: 2022-07-09 06:37 UTC (History)
15 users (show)

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


Attachments
build.log.xz (build.log.xz,98.13 KB, application/x-xz)
2018-01-16 16:39 UTC, Christian
Details
emerge --info output (emerge.info,20.72 KB, text/plain)
2018-01-16 16:40 UTC, Christian
Details
Log of building process (build.log.gz,516.58 KB, application/x-gzip)
2022-07-07 04:27 UTC, Edgar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian 2018-01-16 16:36:45 UTC
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
Comment 1 Christian 2018-01-16 16:39:26 UTC
Created attachment 515038 [details]
build.log.xz
Comment 2 Christian 2018-01-16 16:40:01 UTC
Created attachment 515040 [details]
emerge --info output
Comment 3 Alessandro Vietta 2018-01-20 12:18:09 UTC
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
Comment 4 Christian 2018-01-22 13:12:28 UTC
I have seen this too, but unfortunately, I don't have some older gcc around anymore...
Comment 5 Alessandro Vietta 2018-01-22 20:09:21 UTC
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.
Comment 6 Sergei Trofimovich (RETIRED) gentoo-dev 2018-01-22 22:40:58 UTC
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.
Comment 7 Christian 2018-01-23 10:39:33 UTC
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
Comment 8 Sergei Trofimovich (RETIRED) gentoo-dev 2018-01-23 19:57:16 UTC
Interesting. does 'ar' SIGSEGV if you just rerun 'make'? stracing that would be a good idea as well.
Comment 9 Christian 2018-01-24 12:21:28 UTC
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?
Comment 10 Manuel Lauss 2018-01-26 08:22:28 UTC
temporarily unmerge sys-devel/llvmgold, then the build succeeds.
Comment 11 Christian 2018-01-31 09:54:14 UTC
Surprisingly, uninstalling llvm-gold makes it possible to emerge older gcc.

But question for me remains:
Why is llvm involved in building gcc?
Comment 12 Sergei Trofimovich (RETIRED) gentoo-dev 2018-01-31 19:57:50 UTC
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.
Comment 13 Sergei Trofimovich (RETIRED) gentoo-dev 2019-08-11 17:04:03 UTC
*** Bug 648410 has been marked as a duplicate of this bug. ***
Comment 14 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2019-08-12 16:03:53 UTC
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
Comment 15 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2019-08-12 19:45:55 UTC
#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 ?? ()
Comment 16 Sergei Trofimovich (RETIRED) gentoo-dev 2019-08-17 09:29:09 UTC
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?
Comment 17 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2019-08-17 18:29:56 UTC
(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.
Comment 18 Sergei Trofimovich (RETIRED) gentoo-dev 2019-12-29 14:48:14 UTC
*** Bug 636104 has been marked as a duplicate of this bug. ***
Comment 19 Sergei Trofimovich (RETIRED) gentoo-dev 2020-01-12 22:27:46 UTC
*** Bug 705302 has been marked as a duplicate of this bug. ***
Comment 20 Sergei Trofimovich (RETIRED) gentoo-dev 2020-01-13 19:48:08 UTC
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).
Comment 22 Mihai Moldovan 2020-12-17 02:16:31 UTC
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.
Comment 23 Sergei Trofimovich (RETIRED) gentoo-dev 2020-12-17 07:37:48 UTC
(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++.
Comment 24 Mihai Moldovan 2020-12-17 10:38:31 UTC
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.
Comment 25 Sergei Trofimovich (RETIRED) gentoo-dev 2020-12-17 11:23:44 UTC
(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.
Comment 26 Mihai Moldovan 2020-12-19 08:54:12 UTC
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.
Comment 27 Sergei Trofimovich (RETIRED) gentoo-dev 2020-12-19 10:18:59 UTC
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
Comment 28 Fabio Coatti 2021-06-19 16:58:14 UTC
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.
Comment 29 Sergei Trofimovich (RETIRED) gentoo-dev 2021-06-19 18:35:19 UTC
(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.
Comment 30 Fabio Coatti 2021-06-28 18:53:03 UTC
(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!
Comment 31 Fabio Coatti 2021-07-29 09:35:57 UTC
Same issue, with binutils compiled with gold support, happens with sys-devel/gcc-10.3.0-r2
Comment 32 Edgar 2022-07-07 04:25:17 UTC
(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
Comment 33 Edgar 2022-07-07 04:27:15 UTC
Created attachment 790463 [details]
Log of building process

The building process breaks when compiling cc1plus
Comment 34 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-07-07 04:49:01 UTC
(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.
Comment 35 Attila Tóth 2022-07-07 18:21:35 UTC
(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.
Comment 36 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-07-07 18:38:59 UTC
Indeed, I think this might be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688.
Comment 37 Edgar 2022-07-09 06:37:07 UTC
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.