Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 644772 - sys-devel/gcc: (with sys-devel/llvmgold) - ../libtool: line 1132: 8323 Segmentation fault /usr/x86_64-pc-linux-gnu/bin/ar rc .libs/libstdc++.a compatibility.o compatibility-debug_list.o ...
Summary: sys-devel/gcc: (with sys-devel/llvmgold) - ../libtool: line 1132: 8323 Segme...
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:
: 648410 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-01-16 16:36 UTC by Christian
Modified: 2019-08-18 03:10 UTC (History)
10 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

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 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 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 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 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) 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) 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 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) 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.