[SOLVED] libtool ar segmentation fault when building older gcc version

nrar · 2019-08-17 15:35:39

On several machines (based on AMD Threadripper 1950x, Intel Haswell or Skylake processors) I unable to build aur gcc7 or community gcc8 (using community PKGBUILD) packages due to ar segmentation fault:

ix.io/1S0X

On kernel log I get:

Aug 17 14:02:52 sc17 systemd[1]: systemd-coredump@0-26568-0.service: Succeeded.
Aug 17 14:02:52 sc17 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-26568-0 comm="systemd" exe="/usr/lib/systemd/systemd" hos>
Aug 17 14:02:52 sc17 kernel: audit: type=1131 audit(1566039772.150:37): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-26568-0 comm="systemd" exe="/>
Aug 17 14:02:52 sc17 systemd-coredump[26569]: Process 26567 (ar) of user 1000 dumped core.

Stack trace of thread 26567:
#0 0x00007fe903ddfe5f __pthread_initialize_minimal (libpthread.so.0)
#1 0x00007fe903ddf00d _init (libpthread.so.0)
Aug 17 14:02:51 sc17 kernel: audit: type=1130 audit(1566039771.934:36): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-26568-0 comm="systemd" exe="/>
Aug 17 14:02:51 sc17 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-26568-0 comm="systemd" exe="/usr/lib/systemd/systemd" ho>
Aug 17 14:02:51 sc17 systemd[1]: Started Process Core Dump (PID 26568/UID 0).
Aug 17 14:02:51 sc17 systemd[1]: Created slice system-systemd\x2dcoredump.slice.
Aug 17 14:02:51 sc17 kernel: audit: type=1701 audit(1566039771.914:35): auid=1000 uid=1000 gid=1000 ses=1 pid=26567 comm="ar" exe="/usr/bin/ar" sig=11 res=1
Aug 17 14:02:51 sc17 kernel: Code: 00 00 0f 05 89 82 d0 02 00 00 48 8d 82 10 03 00 00 64 48 89 04 25 10 05 00 00 64 c6 04 25 12 06 00 00 01 4c 8b 25 89 41 01 00 <49> 8b 84 2>
Aug 17 14:02:51 sc17 kernel: ar[26567]: segfault at 968 ip 00007fe903ddfe5f sp 00007ffe5cd9e940 error 4 in libpthread-2.29.so[7fe903ddf000+f000]
Aug 17 14:02:51 sc17 audit[26567]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=1 pid=26567 comm="ar" exe="/usr/bin/ar" sig=11 res=1

First it happened with freshly installed AMD machine, but after reinstalling Arch everything is ok. On other machines I get same error, but reinstall is not the way I would like to use. I used !buildflags and !makeflags - same segfault happens. At the same time some other Haswell machines never get this segfault.

Last edited by nrar (2019-08-26 10:11:23)

Lone_Wolf · 2019-08-21 14:44:38

ar: /home/eugen/Software/gcc7/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /usr/lib/libLLVM-8.so)

That appears to be the problem, no idea why a gcc build would use llvm though.

Please add --log to your makepkg command and post the logfiles it creates.

nrar · 2019-08-21 17:38:07

Lone_Wolf wrote:

Please add --log to your makepkg command and post the logfiles it creates.

faulty_build.log

I removed parallel building option in makepkg.conf on both fault and healthy machines (AMD with reinstalled arch, same error before reinstall) to match the building output lines. Here is the log from healthy machine:

healthy_build.log

Comparing these logs I only found the differences in pdflatex existence and last line of ar command (order of files differs but the content is the same).

Lone_Wolf wrote:

That appears to be the problem, no idea why a gcc build would use llvm though.

Thanks for your suggestion but it seems to me the warning always appears when building older gcc versions. You can see the same warning in healthy log. I don't understand why do we need libLLVM, it was installed as a dependency for mesa package.

Last edited by nrar (2019-08-22 11:34:35)

nrar · 2019-08-22 12:49:15

Removing llvm-libs solves the problem and helps building older versions of gcc. Some machines experience this problem, some others do not.
Before using older gcc version I have to remove llvm-libs every time.

Gentoo users also have faced the problem. For unknown reasons binutils decides to load llvm libs.

Is it worth to submit a bug?

Last edited by nrar (2019-08-22 13:36:37)

Lone_Wolf · 2019-08-24 22:21:19

I had a feeling this may be related the llvm gold/LTO plugin and looked at https://llvm.org/docs/GoldPlugin.html .

The introduction specifically states that ar can use that plugin.

Archlinux packages are supposed[1] to be build in clean chroots and those chroots don't have llvm-libs unless it's a dependency.
Put simply : When building any gcc version in a clean chroot this error won't occur .

I doubt very much this will be accepted as an archlinux bug.

This should be documented somewhere though, but there doesn't seem to a wiki page about building gcc yourself.
Sticky comments on the aur page of gcc packages are an alternative.

[1]
repo packages are build in clean chroots, aur packages are often build outside of chroot.

https://wiki.archlinux.org/index.php/De … ean_chroot
https://bbs.archlinux.org/viewtopic.php?id=168421

nrar · 2019-08-26 10:10:51

Lone_Wolf, thank you for a such informative reply!

Anyway, the issue here is not linking llvm libs itself because after Arch reinstall I can build gcc succecfully on one of the machines even with llvm libs warning about GLIBCXX version not present. I also have computers that never meet the problem. But it still can cause segmentation fault in other systems.

It is also possible to set

LD_PRELOAD= /usr/lib/libstdc++.so

before make in PKGBUILD to evade the segfault as others do. (see AUR gcc49)

Arch Linux

#1 2019-08-17 15:35:39

[SOLVED] libtool ar segmentation fault when building older gcc version

#2 2019-08-21 14:44:38

Re: [SOLVED] libtool ar segmentation fault when building older gcc version

#3 2019-08-21 17:38:07

Re: [SOLVED] libtool ar segmentation fault when building older gcc version

#4 2019-08-22 12:49:15

Re: [SOLVED] libtool ar segmentation fault when building older gcc version

#5 2019-08-24 22:21:19

Re: [SOLVED] libtool ar segmentation fault when building older gcc version

#6 2019-08-26 10:10:51

Re: [SOLVED] libtool ar segmentation fault when building older gcc version

Board footer