Gentoolto: sys-libs/libomp-9.0.0 built by GCC with LTO is missing symbols
_sys-libs/libomp-9.0.0_ now has support for omp_get_thread_num. If _sys-libs/libomp-9.0.0_ is built with GCC using -flto, saving the following snippet (taken from tc-has-openmp() in _toolchain-funcs.eclass_) as file _tst.c_:
#include <omp.h>
int main() {
int nthreads, tid, ret = 0;
#pragma omp parallel private(nthreads, tid)
{
tid = omp_get_thread_num();
nthreads = omp_get_num_threads(); ret += tid + nthreads;
}
return ret;
}
and compiling it via clang -fopenmp tst.c -o tst results in:
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/tst-aff2ef.o: in function `.omp_outlined.':
tst.c:(.text+0x6d): undefined reference to `omp_get_thread_num'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: tst.c:(.text+0x75): undefined reference to `omp_get_num_threads'
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
(Note, compiling the snippet with gcc would cause it to link against gcc's _libgomp.so_, not _libomp.so_)
Building _sys-libs/libomp-9.0.0_ without -flto and compiling the same snippet results in success.
Comparing the output of nm -D /usr/lib64/libomp.so | grep omp_get_thread_num after emerging _sys-libs/libomp-9.0.0_ both with and without -flto shows the absence of the symbol when built with -flto. Tested with _gcc-8.3.0_ and _gcc-9.2.0_. Building _sys-libs/libomp-9.0.0_ with CLANG doesn't exhibit the problem.
Peter-Levine
All 15 comments
????
javashin
on 25 Sep 2019
[javashin@hellbox-l440 /mnt/gentoo/var/db/pkg/sys-libs/libomp-9.0.0]$ cat CFLAGS
-O3 -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fipa-pta -fno-semantic-interposition -flto=3 -fuse-linker-plugin -march=native -mfpmath=sse+387 -falign-functions=32 -flimit-function-alignment -fuse-ld=bfd -fno-plt -fno-math-errno -fno-trapping-math -fno-stack-protector -pipe -Wl,-O2 -Wl,--as-needed,-z,now -Wl,--hash-style=gnu
javashin
on 25 Sep 2019
@javashin I'm not sure you are understanding the problem. sys-libs/libomp-9.0.0 seems to build and install fine. But It lacks certain necessary functions, like omp_get_thread_num, that it would have if it wasn't built with -flto.
Peter-Levine
on 25 Sep 2019
Same for me in regards to both missing references and using clang to build successfully with -flto.
I've tried building sys-libs/libomp with -nostdlib in C/CXXFLAGS and the nm command shows that the reference is in there. However, this error pops up upon compiling tst.c:
$ clang -fopenmp tst.c -o tst
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: tst: hidden symbol `__floatunditf' in /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libgcc.a(floatunditf.o) is referenced by DSO
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: bad value
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
When libomp is built with -nostdlib, using ld.lld as the linker during runtime knows to link to the right libraries. It seems, anyway.
$ clang -fopenmp -fuse-ld=lld tst.c -o tst
I've tried using lld as the linker during ebuild and it failed. I've also tried building clang with USE default-libcxx and that didn't help, either.
jiblime
on 27 Sep 2019
It seems much more ideal to use Clang to build anything LLVM/Clang related, so I've been testing out a package.env replacement that would most closely replicate GentooLTO's flags. Below is the equivalent to CFLAGS="-march=native -O3 ${FLTO} ${NOPLT} ${SAFEST_FAST_MATH} -pipe -fuse-ld=lld". Using -flto automatically implies -flto=jobserver.
USE="clang"
CC="clang"
CXX="clang++"
CFLAGS="-march=native -O3 -flto=thin -fno-plt -fno-math-errno -fno-trapping-math -pipe -fuse-ld=lld"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,--lto-O1 -Wl,-O1 -Wl,--as-needed -fuse-ld=lld"
# Other possible configurations that work:
# LDFLAGS="-Wl,-O1 -Wl,--as-needed -fuse-ld=lld"
# LDFLAGS="-Wl,--lto-O3 -Wl,-O3 -Wl,--as-needed -fuse-ld=lld"
# LDFLAGS="-Wl,--lto-O3 -Wl,-O3 -Wl,--as-needed -Wl,-z,relro,-z,now -ffunction-sections -Wl,--gc-sections -fuse-ld=lld"
NOLDADD=1
USE_NONGNU=0 # strips -fno-plt
To note, NOLDADD and USE_NONGNU are courtesy of vaeth's app-portage/portage-bashrc-mv, a dep of sys-config/ltoize. NOLDADD adds LDFLAGS to all other *FLAGS, and for Clang it results in unnecessary warnings. USE_NONGNU looks to be made for Clang <=8 to filter out GCC specific flags, and wouldn't be needed when using a specialized env file anyways.
About linking: -fuse-ld=lld is used to prefer ld.lld in case using ld.bfd or ld.gold would result in strange linking issues. I'm unsure of the benefits7 of optimizing up to -Wl,--lto-O3 -Wl,-O3.
With LDFLAGS="-Wl,--lto-O3 -Wl,-O3 -Wl,--as-needed -Wl,-z,relro,-z,now -ffunction-sections -Wl,--gc-sections -fuse-ld=lld", Firefox actually saw an increase in binary size by a few megabytes vs. its -O1 brother. Using https://krakenbenchmark.mozilla.org/kraken-1.1/driver to benchmark, I didn't see much variance in GCC vs. Clang -Wl,-O3 vs. Clang -Wl,-O1.
And if building sys-libs/compiler-rt-sanitizers with Clang/-fno-plt, this needs to be added to whichever package.cflags file of your choice:
sys-libs/compiler-rt-sanitizers *FLAGS-="-fno-plt" # fails to build with clang-9
Question: Would it be better to use package.cflags for this? If so, what would an implementation look like?
jiblime
on 4 Oct 2019
i don't know about lld, but for binutils -O1 is is as good as it gets
On Fri, Oct 4, 2019, 03:22 jiblime notifications@github.com wrote:
It seems much more ideal to use Clang to build anything LLVM/Clang
related, so I've been testing out a package.env replacement that would most
closely replicate GentooLTO's flags. Below is the equivalent to CFLAGS="-march=native
-O3 ${FLTO} ${NOPLT} ${SAFEST_FAST_MATH} -pipe -fuse-ld=lld". Using -flto
automatically implies -flto=jobserver.USE="clang"
CC="clang"
CXX="clang++"CFLAGS="-march=native -O3 -flto=thin -fno-plt -fno-math-errno -fno-trapping-math -pipe -fuse-ld=lld"
CXXFLAGS="${CFLAGS}"LDFLAGS="-Wl,--lto-O1 -Wl,-O1 -Wl,--as-needed -fuse-ld=lld"
Other possible configurations that work:
LDFLAGS="-Wl,--lto-O3 -Wl,-O3 -Wl,--as-needed -fuse-ld=lld"
LDFLAGS="-Wl,--lto-O3 -Wl,-O3 -Wl,--as-needed -Wl,-z,relro,-z,now -ffunction-sections -Wl,--gc-sections -fuse-ld=lld"
NOLDADD=1
USE_NONGNU=0 # strips -fno-pltTo note, NOLDADD and USE_NONGNU are courtesy of vaeth's
app-portage/portage-bashrc-mv, a dep of sys-config/ltoize. NOLDADD adds
LDFLAGS to all other *FLAGS, and for Clang it results in unnecessary
warnings. USE_NONGNU looks to be made for Clang <=8 to filter out GCC
specific flags, and wouldn't be needed when using a specialized env file
anyways.I'm unsure of the benefits of optimizing up to -Wl,--lto-O3 -Wl,-O3.
With LDFLAGS="-Wl,--lto-O3 -Wl,-O3 -Wl,--as-needed -Wl,-z,relro,-z,now
-ffunction-sections -Wl,--gc-sections -fuse-ld=lld", Firefox actually saw
an increase in binary size by a few megabytes vs. its -O1 brother. Using
https://krakenbenchmark.mozilla.org/kraken-1.1/driver to benchmark, I
didn't see much variance in GCC vs. Clang -Wl,-O3 vs. Clang -Wl,-O1.And if building sys-libs/compiler-rt-sanitizers with Clang/-fno-plt, this
needs to be added to whichever package.cflags file of your choice:sys-libs/compiler-rt-sanitizers *FLAGS-="-fno-plt" # fails to build with
clang-9—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/InBetweenNames/gentooLTO/issues/417?email_source=notifications&email_token=AAAHXYWF2QFKIEAFLMXDFBLQM4KMZA5CNFSM4I2HOQJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEALG5FI#issuecomment-538341013,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAHXYSQMDRPSVGEGS6LOMDQM4KMZANCNFSM4I2HOQJQ
.
wolfwood
on 4 Oct 2019
I took a look for lld, current documentation states there are 3 levels, -O{0,1,2}. -O1 is default.
-O0 -- Disable string merging.
-O1 -- Enable string merging.
-O2 -- Enable string tail merging.
Curiously, this implies that a lower level will result in better performance. I'm guessing they meant that linking is faster with a lower level, but I've tested it and ebuild time varies by <5 minutes, so not enough to determine anything.
The difference between the largest and smallest final binaries I got for Firefox wasn't greater than 1MB. Chromium devs default to -O2 for a whopping 150KB reduction in size.
So actually it almost doesn't matter just like ld.bfd...
Firefox fails to build if --lto-O0 is set, so stuff was learned I guess
jiblime
on 5 Oct 2019
Curiously, this implies that a lower level will result in better performance.
Not sure where you're seeing that.
Peter-Levine
on 5 Oct 2019
Curiously, this implies that a lower level will result in better performance.
Not sure where you're seeing that.
You're right, I assumed size and performance were working opposite of each other in this case.
I'm curious what *FLAGS do you use to build the LLVM/Clang environment. I've been encountering a lot of compiler failures that I haven't been able to pin down so I've stuck -O2 -march=native -pipe onto anything that is or is built with LLVM.
jiblime
on 11 Nov 2019
I'm curious what *FLAGS do you use to build the LLVM/Clang environment
For building with clang I set in the environment:
CC=clang
CXX=clang++
AR=llvm-ar
NM=llvm-nm
RANLIB=llvm-ranlib
STRIP=llvm-strip
If building chromium, I also set CFLAGS="${CFLAGS} -fuse-ld=gold" because there are link failures that for some reason don't occur with the gold linker. Also, for some chromium builds there is a serious problem with USE=custom-cflags in which the LDFLAGS are emitted before -pthread is. If -Wl,--as-needed is used in LDFLAGS, this leads to build failure with many undefined pthread symbols. I patch the build to redundantly include -pthread before LDFLAGS. Also, I still have the problem from https://github.com/InBetweenNames/gentooLTO/issues/278 so I have to compile dev-libs/re2 without lto before building chromium or it sporadically segfaults.
C{XX}FLAGS, after filtered and adjusted by portage-bashrc-mv, is -march=haswell -mtune=skylake -O3 -flto=thin -falign-functions=32 -pipe -fstack-check. LDFLAGS are default.
In terms of testing with systemwide clang, there were only a few packages I couldn't build:
dev-libs/elfutils-0.177
dev-lang/spidermonkey-1.8.5-r9
sys-devel/gcc
sys-libs/glibc
media-video/ffmpeg-4.2.1
Most others I was able to workaround.
Peter-Levine
on 13 Nov 2019
Also, for some chromium builds there is a serious problem with USE=custom-cflags in which the LDFLAGS are emitted before -pthread is. If -Wl,--as-needed is used in LDFLAGS, this leads to build failure with many undefined pthread symbols.
This is happening to the packages I need the most. I recall the same issue happening with an older revision of mesa, and my backtraces do include mesa/glibc/qtxcb. As I understand, declaring -pthread in CFLAGS will set -lpthread in LDFLAGS and the CPP flag -D_REENTRANT=1.
But then it still doesn't work, so removing --as-needed is the fix to apply, correct? There is this Gentoo wiki page on this subject. I'm trying to understand why it's causing breakage. readelf -d shows that libpthread is linked in, so does that mean libpthread is missing symbols or it has its own libraries that were punted?
I didn't realize the list of Clang incompatibles would be so short. @javashin might know something about compiling glibc with Clang, I recall he has/had OpenMageia.
I just failed building chromium::gentoo with both bfd/gold, during GIMPLE pass: graphite. Could be a bad toolchain...I'll try out what you did and what was mentioned in #287.
Edit: for the record failed with
CFLAGS="-O3 -march=native -fgraphite-identity -floop-nest-optimize -fdevirtualize-at-ltrans -fno-semantic-interposition -fno-math-errno -fno-trapping-math -flto -pipe -falign-functions=32 -fuse-linker-plugin"
USE="closure-compile cups custom-cflags hangouts jumbo-build (pic) proprietary-codecs pulseaudio suid system-ffmpeg system-icu tcmalloc
Regarding dev-libs/re2, I sometimes will grep my logdir for packages that need -ffat-lto-objects and re2 is one of them. I've noted that anything that installs static libraries or is a crate from the Rust language will most likely need -ffat-lto-objects or -fno-lto. I only treat this as a safety net because I didn't find any bugs prior to rebuilding them, with the exception of nearly ever crate I emerged.
This is the command I use to find packages and judge their 'severity' by number of times "plugin needed" was in a build.
grep -rs 'plugin\ needed' /var/log/portage/build | sed 's/\(.*log\).*/\1/g' | uniq -c
13 /var/log/portage/build/dev-lang/ocaml-4.05.0-r1:20191110-001144.log
And this is the command I use to add them to a filter file + append the current version number, it will occasionally break because sometimes package name syntax is odd:
grep -rs 'plugin\ needed' /var/log/portage/build | sed 's/\(.*\):.*log.*/\1/g ; s/\(.*[aA-zZ]\)\-\(.*\)/\1\t\t\*FLAGS+=\-ffat\-lto\-objects\ \#\ \2/g' | sort -u >> /etc/portage/package.cflags/add-fat.conf
Here is a part of the list of packages that I've emerged that had plugin needed to handle lto object in their build.log:
# Based on grepping /var/log/portage/build dir
# These are ebuilds that with logs that contained:
# "plugin needed to handle lto object"
# All ebuilds sourced from the gentoo master tree;
# exceptions being the Python ebuilds from lto-overlay
app-emulation/lxd *FLAGS+=-ffat-lto-objects # 3.16
app-emulation/lxc *FLAGS+=-ffat-lto-objects # 3.1.0-r1
app-emulation/vkd3d *FLAGS+=-ffat-lto-objects # 1.1
dev-libs/re2 *FLAGS+=-ffat-lto-objects
dev-lang/python *FLAGS+=-ffat-lto-objects # Slots 3.6 and 3.7 were known to emit warnings. 3.6.9 and 3.7.4 specifically were tested
dev-lang/tk *FLAGS+=-ffat-lto-objects # 8.6.9.1 This one is a 15% increase in size for one mention of needing a plugin. It'd be better to patch the ebuild in this case
dev-lang/tcl *FLAGS+=-ffat-lto-objects # 8.6.9
dev-libs/boost *FLAGS+=-ffat-lto-objects # 1.71.0
dev-libs/newt *FLAGS+=-ffat-lto-objects # 0.52.21
dev-libs/libassuan *FLAGS+=-ffat-lto-objects # 2.5.3
#dev-qt/qtgui *FLAGS+=-ffat-lto-objects # 5.12.5
dev-util/glslang *FLAGS+=-ffat-lto-objects # 7.11.3114_pre20190415-r1
media-libs/x265 *FLAGS+=-ffat-lto-objects # 3.2
media-libs/libprojectm *FLAGS+=-ffat-lto-objects # 3.1.1_rc4
media-video/movit *FLAGS+=-ffat-lto-objects # 1.6.2
media-video/vlc *FLAGS+=-ffat-lto-objects # 3.0.8
net-fs/nfs-utils *FLAGS+=-ffat-lto-objects # 2.4.1-r2
sys-apps/iproute2 *FLAGS+=-ffat-lto-objects # 5.3.0
sys-libs/libunwind *FLAGS+=-ffat-lto-objects # 1.2.1-r3
sys-libs/db *FLAGS+=-ffat-lto-objects # 5.3.28-r3
dev-util/pkgconf *FLAGS+=-ffat-lto-objects # 1.6.3
app-antivirus/clamav *FLAGS+=-ffat-lto-objects # 101.4/102.0
dev-libs/libatomic_ops *FLAGS+=-ffat-lto-objects # 7.6.10
dev-db/postgresql *FLAGS+=-ffat-lto-objects # 12.0
app-arch/brotli *FLAGS+=-ffat-lto-objects # 1.0.7
dev-lang/yasm *FLAGS+=-ffat-lto-objects # 1.3.0
media-libs/xvid *FLAGS+=-ffat-lto-objects # 1.3.5
dev-qt/qtdeclarative *FLAGS+=-ffat-lto-objects # 5.12.5
sys-devel/flex *FLAGS+=-ffat-lto-objects # 2.6.4-r1
# New additions | The prefixed number is the number of times a file needed an 'lto plugin' per ebuild
# 10 dev-qt/designer-5.13.1:20191022-160716.log
# 14 dev-util/colm-0.13.0.5:20191022-114105.log
# 10 media-libs/shaderc-2019.0:20191022-092732.log
# 1 media-libs/libsdl-1.2.15-r9:20191022-155751.log
# 64 sys-libs/binutils-libs-2.32-r1:20191022-103523.log
# 29 dev-lang/lua-5.1.5-r102:20191022-120337.log
# 29 dev-lang/lua-5.1.5-r4:20191022-105506.log
# 32 dev-lang/lua-5.2.4-r1:20191022-115516.log
# 16 media-gfx/exiv2-0.27.2:20191022-174929.log
# 16 media-gfx/exiv2-0.27.2:20191022-163208.log
dev-lang/lua *FLAGS+=-ffat-lto-objects # 5.1.5-r4 (slot 0) | 5.1.5-r102 (slot 5.1) | 5.2.4-r1 (slot 5.2)
dev-qt/designer *FLAGS+=-ffat-lto-objects # 5.13.1
dev-util/colm *FLAGS+=-ffat-lto-objects # 0.13.0.5
media-gfx/exiv2 *FLAGS+=-ffat-lto-objects # 0.27.2
media-libs/libsdl *FLAGS+=-ffat-lto-objects # 1.2.15-r9
media-libs/shaderc *FLAGS+=-ffat-lto-objects # 2019.0
sys-libs/binutils-libs *FLAGS+=-ffat-lto-objects # 2.32-r1
# Suspect the builds below emit "plugin needed to handle lto object"
# only when USE='static-libs' is set. With static-libs globally masked,
# the only failure I've encountered is USE='static' sys-apps/busybox
# failing when sys-libs/glibc is built with -static-libs.
# Notes ~ dracut and genkernel don't use busybox for initrd generation
# Notes ~ Haven't tested Wine emulation with -static-libs
sys-libs/zlib *FLAGS+=-ffat-lto-objects # 1.2.11-r2
net-misc/curl *FLAGS+=-ffat-lto-objects # 7.66.0
dev-libs/libgcrypt *FLAGS+=-ffat-lto-objects # 1.8.5
dev-libs/npth *FLAGS+=-ffat-lto-objects # 1.6-r1
dev-libs/libksba *FLAGS+=-ffat-lto-objects # 1.3.5-r2
sys-libs/ncurses *FLAGS+=-ffat-lto-objects # 6.1_p20190609
dev-util/cargo-tree *FLAGS+=-ffat-lto-objects
As I understand, declaring -pthread in CFLAGS will set -lpthread in LDFLAGS and the CPP flag -D_REENTRANT=1
I was mistaken. It appears I meant -lpthread. Though chromium did emit -pthread on many lines, the offending line apparently emitted -lpthread instead:
FAILED: bytecode_builtins_list_generator
clang++ -pie -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -rdynamic -pie -Wl,--disable-new-dtags -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -flto-jobs=8 -march=haswell -mtune=skylake -O3 -flto=thin -falign-functions=32 -pipe -fstack-check -o "./bytecode_builtins_list_generator" -Wl,--start-group @"./bytecode_builtins_list_generator.rsp" -Wl,--end-group -latomic -ldl -lpthread -lrt
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so: undefined reference to `pthread_rwlock_unlock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so: undefined reference to `pthread_create'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so: undefined reference to `pthread_key_create'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so: undefined reference to `pthread_getspecific'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so: undefined reference to `pthread_key_delete'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so: undefined reference to `pthread_rwlock_rdlock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so: undefined reference to `pthread_rwlock_wrlock'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so: undefined reference to `pthread_join'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so: undefined reference to `pthread_setspecific'
But then it still doesn't work, so removing --as-needed is the fix to apply, correct? There is this Gentoo wiki page on this subject. I'm trying to understand why it's causing breakage. readelf -d shows that libpthread is linked in, so does that mean libpthread is missing symbols or it has its own libraries that were punted?
There seems to be an interesting explanation here. I have been using this diff to deal with it in chromium but perhaps including -pthread in CXXFLAGS would have worked. I don't remember if I tested for that but I do remember that the position of -lpthread relative to -Wl,--as-needed was the factor determining link success or failure, all other things being equal.
I just failed building chromium::gentoo with both bfd/gold, during GIMPLE pass: graphite.
I can't remember the last time I successfully built chromium with gcc. clang + gold just gave consistently fewer headaches so I stuck with it.
Regarding dev-libs/re2, I sometimes will grep my logdir for packages that need -ffat-lto-objects and re2 is one of them.
Yes, it appears that that would likely have sufficed.
Peter-Levine
on 14 Nov 2019
Noted on chromium not building with GCC. I don't think it will be too far in the future where chromium/Firefox devs will stop caring about GCC compatibility. Apparently Clang is heavenly for them because of better debugging/thinLTO cache/licensing.
There seems to be an interesting explanation here
Part I found most interesting from that:
If an application calls "open" and is linked against libpthread and libc (which
both provide a version of "open", one thread-aware the other not) then the
dynamic linker will chose the first it finds. Other things (gcc .spec
files) make sure that libpthread is linked in _before_ libc when -pthread
is given. This can't be ensured for -lpthread, the latter being simply a
request for a random other library, as far as the system knows. So only
-pthread, not -lpthread, makes really sure that libpthread is linked at
the right place vs. libc, so that it can override the non thread-aware
functions of it.
The commit title on the linked diff helps. For mesa I have tried using, instead of --as-needed, --no-as-needed. Like such:
LDFLAGS="-Wl,-O1 -Wl,-E -Wl,--no-as-needed -lpthread -lc
-E exports all dynamic symbols and --no-as-needed means that the libraries added after it are required to be linked even if they aren't used. Still didn't work, so I'll try putting -lpthread before --as-needed as suggested.
I've also tried looking at the offending libraries that cause runtime errors in programs for undefined symbols. I'm hoping this can be a lead as to why this is happening if there is more than one reason pthread is causing issues. These are undefined symbols in the libraries that are shown in backtraces when something crashes and pthread is involved for my own system (currently, still testing linking flags):
nm - list symbols from object files
-C [Decode low-level symbol names into user-level names, default auto]
-D [Display dynamic symbols instead of normal symbols]
-u [Display only undefined symbols]
$ nm -C -D -u /usr/lib64/libQt5Core.so.5
---
U abort
U access
U acos
U asin
U __assert_fail
U atan2
U backtrace
U backtrace_symbols
U calloc
U chdir
U chmod
U clock_gettime
U close
U closedir
U compress2
U cos
U __cxa_allocate_exception
U __cxa_atexit
U __cxa_begin_catch
U __cxa_demangle
U __cxa_end_catch
w __cxa_finalize
U __cxa_guard_abort
U __cxa_guard_acquire
U __cxa_guard_release
U __cxa_pure_virtual
U __cxa_rethrow
U __cxa_throw
U __cxa_throw_bad_array_new_length
U dlclose
U dlerror
U dlopen
U dlsym
U dup3
U endmntent
U environ
U __errno_location
U eventfd
U eventfd_read
U eventfd_write
U execv
U execve
U _exit
U exit
U fchmod
U fclose
U fcntl
U fdatasync
U feof
U fflush
U fgetc
U fgets
U fileno
U flock
U fopen
U fork
U __fprintf_chk
U fputs
U fread
U __fread_chk
U free
U fseeko64
U ftello64
U ftok
U ftruncate
U ftruncate64
U futimens
U fwrite
U __fxstat64
U __gcc_personality_v0
U getcwd
U getentropy
U getenv
U geteuid
U getgrgid_r
U getmntent_r
U getpagesize
U getpid
U getpwuid_r
U gettimeofday
U getuid
U g_main_context_default
U g_main_context_iteration
U g_main_context_new
U g_main_context_pending
U g_main_context_pop_thread_default
U g_main_context_push_thread_default
U g_main_context_ref
U g_main_context_unref
U g_main_context_wakeup
w __gmon_start__
U g_source_add_poll
U g_source_attach
U g_source_destroy
U g_source_new
U g_source_remove_poll
U g_source_set_can_recurse
U g_source_unref
U __gxx_personality_v0
U inotify_add_watch
U inotify_init
U inotify_init1
U inotify_rm_watch
U ioctl
U isatty
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U kill
U link
U linkat
U localtime_r
U log10
U lseek
U lseek64
U __lxstat64
U malloc
U memchr
U memcmp
U memcpy
U __memcpy_chk
U memmove
U memset
U __memset_chk
U mkdir
U mktime
U mmap64
U munmap
U nanosleep
U __once_proxy
U open64
U opendir
U pcre2_code_free_16
U pcre2_compile_16
U pcre2_config_16
U pcre2_get_error_message_16
U pcre2_get_ovector_pointer_16
U pcre2_jit_compile_16
U pcre2_jit_stack_assign_16
U pcre2_jit_stack_create_16
U pcre2_jit_stack_free_16
U pcre2_match_16
U pcre2_match_context_create_16
U pcre2_match_context_free_16
U pcre2_match_data_create_from_pattern_16
U pcre2_match_data_free_16
U pcre2_pattern_info_16
U pcre2_substring_number_from_name_16
U perror
U pipe2
U pow
U ppoll
U __ppoll_chk
U prctl
U __printf_chk
U pthread_attr_destroy
U pthread_attr_getschedpolicy
U pthread_attr_init
U pthread_attr_setdetachstate
U pthread_attr_setinheritsched
U pthread_attr_setschedparam
U pthread_attr_setschedpolicy
U pthread_attr_setstacksize
U pthread_cancel
U pthread_condattr_destroy
U pthread_condattr_init
U pthread_condattr_setclock
U pthread_cond_broadcast
U pthread_cond_destroy
U pthread_cond_init
U pthread_cond_signal
U pthread_cond_timedwait
U pthread_cond_wait
U pthread_create
U pthread_getschedparam
w __pthread_key_create
U pthread_key_create
U pthread_key_delete
U pthread_mutex_destroy
U pthread_mutex_init
U pthread_mutex_lock
U pthread_mutex_unlock
U pthread_once
U pthread_self
U pthread_setcancelstate
U pthread_setschedparam
U pthread_setspecific
U pthread_testcancel
U puts
U read
U readdir64
U readlink
U realloc
U realpath
U rename
U renameat2
U rmdir
U sched_get_priority_max
U sched_get_priority_min
U sched_yield
U sd_journal_send
U semctl
U semget
U semop
U sendfile
U setenv
U setlocale
U setmntent
U setsid
U shmat
U shmctl
U shmdt
U shmget
U sigaction
U sigemptyset
U signal
U sin
U sincos
U __sprintf_chk
U __stack_chk_fail
U statvfs64
U statx
U stderr
U stdout
U strchr
U strcmp
U strcpy
U strcspn
U strdup
U strerror
U strlen
U strncmp
U strncpy
U strrchr
U strstr
U symlink
U syscall
U sysconf
U times
U timezone
U __tls_get_addr
U truncate64
U tzname
U tzset
U ucal_clone
U ucal_close
U ucal_get
U ucal_getDefaultTimeZone
U ucal_getDSTSavings
U ucal_getTimeZoneDisplayName
U ucal_inDaylightTime
U ucal_open
U ucal_openCountryTimeZones
U ucal_openTimeZoneIDEnumeration
U ucal_openTimeZones
U ucal_setMillis
U ucnv_close
U ucnv_compareNames
U ucnv_countAliases
U ucnv_countAvailable
U ucnv_fromUnicode
U ucnv_getAlias
U ucnv_getAvailableName
U ucnv_getDefaultName
U ucnv_getMaxCharSize
U ucnv_getStandardName
U ucnv_open
U ucnv_setSubstChars
U ucnv_toUnicode
U ucol_close
U ucol_getSortKey
U ucol_open
U ucol_setAttribute
U ucol_strcoll
U uenum_close
U uenum_next
U u_errorName
U uname
U uncompress
U unlink
U unsetenv
U _Unwind_Resume
U u_strToLower
U u_strToUpper
U __vsnprintf_chk
U wait4
U waitid
U waitpid
U write
U __xstat64
U operator delete[](void*)
U operator delete[](void*, unsigned long)
U operator delete(void*)
U operator delete(void*, unsigned long)
U double_conversion::DoubleToStringConverter::DoubleToAscii(double, double_conversion::DoubleToStringConverter::DtoaMode, int, char*, int, bool*, int*, int*)
U operator new[](unsigned long)
U operator new[](unsigned long, std::nothrow_t const&)
U double_conversion::StringToDoubleConverter::StringToDouble(char const*, int, int*) const
U std::exception::what() const
U std::__exception_ptr::exception_ptr::exception_ptr(std::__exception_ptr::exception_ptr const&)
U std::__exception_ptr::exception_ptr::~exception_ptr()
U std::__exception_ptr::operator==(std::__exception_ptr::exception_ptr const&, std::__exception_ptr::exception_ptr const&)
U std::__atomic_futex_unsigned_base::_M_futex_wait_until(unsigned int*, unsigned int, bool, std::chrono::duration
$ nm -C -D -u /lib64/libc.so.6
--- U _dl_argv U _dl_exception_create U _dl_find_dso_for_object w _dl_starting_up U __libc_enable_secure w __libdl_freeres w __libpthread_freeres U _rtld_global U _rtld_global_ro U __tls_get_addr U __tunable_get_val ---
$ nm -C -D -u /lib64/libpthread.so.0
--- U abort U __assert_fail U calloc U __call_tls_dtors U __clock_gettime U __clone U __close_nocancel U __ctype_init w __cxa_finalize U _dl_allocate_tls U _dl_allocate_tls_init U _dl_deallocate_tls U _dl_get_tls_static_info U _dl_make_stack_executable U __endmntent U errno U _exit U exit U fclose U fopen U free U __fxstat64 U __getdelim U __getmntent_r U __getpagesize U __getpid U getpid U __getrlimit U getrlimit U __gettimeofday U getuid U __h_errno U _IO_enable_locks U __isoc99_sscanf w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable U __libc_alloca_cutoff U __libc_allocate_rtsig_private U __libc_current_sigrtmax_private U __libc_current_sigrtmin_private U __libc_dlclose U __libc_dlopen_mode U __libc_dlsym U __libc_fatal U __libc_fcntl64 U __libc_fork U __libc_longjmp U __libc_pthread_init U __libc_siglongjmp U __libc_stack_end U __libc_system U __libc_thread_freeres U link U __madvise U malloc U memcpy U __mempcpy U memset U __mktemp U __mmap U mmap U __mprotect U __munmap U munmap U __nanosleep_nocancel U __open64_nocancel U __pause_nocancel U prctl U __read_nocancel U realloc U __register_atfork U __resp U _rtld_global U _rtld_global_ro U __sched_getparam U __sched_get_priority_max U __sched_get_priority_min U __sched_getscheduler U sched_setparam U __sched_setscheduler U sched_yield U _setjmp U __setmntent U __sigtimedwait U sprintf U __stack_chk_fail U __statfs U strchr U strcmp U strlen U __tdelete U __tfind U __tsearch U __tunable_get_val U __twalk_r U unlink U __write_nocancel ---
--- ---
$ nm -C -D -u /usr/lib64/dri/radeonsi_dri.so
U abort
U accept
U access
U alphasort64
U amdgpu_bo_alloc
U amdgpu_bo_cpu_map
U amdgpu_bo_cpu_unmap
U amdgpu_bo_export
U amdgpu_bo_free
U amdgpu_bo_import
U amdgpu_bo_list_create_raw
U amdgpu_bo_list_destroy_raw
U amdgpu_bo_query_info
U amdgpu_bo_set_metadata
U amdgpu_bo_va_op
U amdgpu_bo_va_op_raw
U amdgpu_bo_wait_for_idle
U amdgpu_create_bo_from_user_mem
U amdgpu_cs_chunk_fence_info_to_data
U amdgpu_cs_chunk_fence_to_dep
U amdgpu_cs_create_syncobj
U amdgpu_cs_create_syncobj2
U amdgpu_cs_ctx_create
U amdgpu_cs_ctx_free
U amdgpu_cs_destroy_syncobj
U amdgpu_cs_fence_to_handle
U amdgpu_cs_import_syncobj
U amdgpu_cs_query_fence_status
U amdgpu_cs_query_reset_state
U amdgpu_cs_query_reset_state2
U amdgpu_cs_submit_raw2
U amdgpu_cs_syncobj_export_sync_file
U amdgpu_cs_syncobj_import_sync_file
U amdgpu_cs_syncobj_wait
U amdgpu_device_deinitialize
U amdgpu_device_initialize
U amdgpu_get_marketing_name
U amdgpu_query_buffer_size_alignment
U amdgpu_query_firmware_version
U amdgpu_query_gds_info
U amdgpu_query_gpu_info
U amdgpu_query_heap_info
U amdgpu_query_hw_ip_info
U amdgpu_query_info
U amdgpu_query_sensor_info
U amdgpu_query_sw_info
U amdgpu_read_mm_registers
U amdgpu_va_range_alloc
U amdgpu_va_range_free
U amdgpu_vm_reserve_vmid
U amdgpu_vm_unreserve_vmid
U __asprintf_chk
U __assert_fail
U atan2f
U atanf
U bind
U calloc
U clearerr
U clock_gettime
U clock_nanosleep
U close
U closedir
U connect
U cos
U cosf
U crc32
U __ctype_b_loc
U __cxa_atexit
U __cxa_begin_catch
U __cxa_end_catch
w __cxa_finalize
U __cxa_guard_acquire
U __cxa_guard_release
U __cxa_pure_virtual
U __cxa_rethrow
U __cxa_throw_bad_array_new_length
U deflate
U deflateEnd
U deflateInit_
U dirfd
U __divti3
U dladdr
U dlclose
U dlerror
U dl_iterate_phdr
U dlopen
U dlsym
U drmCommandWrite
U drmCommandWriteRead
U drmFreeDevice
U drmFreeDevices
U drmFreeVersion
U drmGetCap
U drmGetDevice2
U drmGetDeviceNameFromFd2
U drmGetDevices2
U drmGetVersion
U drmIoctl
U drmPrimeFDToHandle
U drmPrimeHandleToFD
U dup
U elf64_getehdr
U elf64_getshdr
U elf_end
U elf_errmsg
U elf_errno
U elf_getdata
U elf_getscn
U elf_getshdrnum
U elf_getshdrstrndx
U elf_memory
U elf_ndxscn
U elf_nextscn
U elf_strptr
U elf_version
U __errno_location
U exit
U exp
U exp2f
U expf
U fclose
U fcntl64
U fdopen
U feof
U ferror
U fflush
U fgets
U fileno
U flock
U fmax
U fmaxf
U fmin
U fminf
U fnmatch
U fopen64
U __fprintf_chk
U fputc
U fputs
U fread
U free
U freeaddrinfo
U freelocale
U frexp
U frexpf
U fseek
U ftell
U ftruncate64
U fwrite
U __fxstat64
U __fxstatat64
U getaddrinfo
U getc
U getenv
U geteuid
U getpid
U getpwuid_r
U getuid
U _glapi_add_dispatch
U _glapi_check_multithread
U _glapi_get_context
U _glapi_get_dispatch
U _glapi_get_dispatch_table_size
U _glapi_set_context
U _glapi_set_dispatch
U _glapi_tls_Context
U _glapi_tls_Dispatch
w __gmon_start__
U __gxx_personality_v0
U inflate
U inflateEnd
U inflateInit_
U ioctl
U isatty
U __isoc99_sscanf
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U kill
U ldexp
U ldexpf
U listen
U LLVMABISizeOfType
U LLVMAddAggressiveDCEPass
U LLVMAddAlwaysInlinerPass
U LLVMAddAttributeAtIndex
U LLVMAddCallSiteAttribute
U LLVMAddCase
U LLVMAddCFGSimplificationPass
U LLVMAddConstantPropagationPass
U LLVMAddCoroCleanupPass
U LLVMAddCoroEarlyPass
U LLVMAddCoroElidePass
U LLVMAddCoroSplitPass
U LLVMAddEarlyCSEMemSSAPass
U LLVMAddEarlyCSEPass
U LLVMAddFunction
U LLVMAddGlobal
U LLVMAddGlobalInAddressSpace
U LLVMAddGVNPass
U LLVMAddIncoming
U LLVMAddInstructionCombiningPass
U LLVMAddLICMPass
U LLVMAddPromoteMemoryToRegisterPass
U LLVMAddReassociatePass
U LLVMAddScalarReplAggregatesPass
U LLVMAddTargetDependentFunctionAttr
U LLVMAddTargetLibraryInfo
U LLVMAddVerifierPass
U LLVMAppendBasicBlockInContext
U LLVMArrayType
U LLVMBasicBlockAsValue
U LLVMBuildAdd
U LLVMBuildAggregateRet
U LLVMBuildAlloca
U LLVMBuildAnd
U LLVMBuildArrayAlloca
U LLVMBuildAShr
U LLVMBuildAtomicCmpXchg
U LLVMBuildAtomicRMW
U LLVMBuildBitCast
U LLVMBuildBr
U LLVMBuildCall
U LLVMBuildCondBr
U LLVMBuildExtractElement
U LLVMBuildExtractValue
U LLVMBuildFAdd
U LLVMBuildFCmp
U LLVMBuildFDiv
U LLVMBuildFence
U LLVMBuildFMul
U LLVMBuildFNeg
U LLVMBuildFPExt
U LLVMBuildFPToSI
U LLVMBuildFPToUI
U LLVMBuildFPTrunc
U LLVMBuildFRem
U LLVMBuildFSub
U LLVMBuildGEP
U LLVMBuildICmp
U LLVMBuildInBoundsGEP
U LLVMBuildInsertElement
U LLVMBuildInsertValue
U LLVMBuildIntCast
U LLVMBuildIntToPtr
U LLVMBuildLoad
U LLVMBuildLShr
U LLVMBuildMul
U LLVMBuildNeg
U LLVMBuildNot
U LLVMBuildNUWAdd
U LLVMBuildNUWMul
U LLVMBuildOr
U LLVMBuildPhi
U LLVMBuildPointerCast
U LLVMBuildPtrToInt
U LLVMBuildRet
U LLVMBuildRetVoid
U LLVMBuildSDiv
U LLVMBuildSelect
U LLVMBuildSExt
U LLVMBuildSExtOrBitCast
U LLVMBuildShl
U LLVMBuildShuffleVector
U LLVMBuildSIToFP
U LLVMBuildSRem
U LLVMBuildStore
U LLVMBuildSub
U LLVMBuildSwitch
U LLVMBuildTrunc
U LLVMBuildTruncOrBitCast
U LLVMBuildUDiv
U LLVMBuildUIToFP
U LLVMBuildURem
U LLVMBuildXor
U LLVMBuildZExt
U LLVMConstAdd
U LLVMConstAllOnes
U LLVMConstAShr
U LLVMConstBitCast
U LLVMConstFAdd
U LLVMConstFDiv
U LLVMConstFMul
U LLVMConstFSub
U LLVMConstInlineAsm
U LLVMConstInsertElement
U LLVMConstInt
U LLVMConstIntGetZExtValue
U LLVMConstLShr
U LLVMConstMul
U LLVMConstNot
U LLVMConstNull
U LLVMConstPointerNull
U LLVMConstReal
U LLVMConstRealGetDouble
U LLVMConstSDiv
U LLVMConstStringInContext
U LLVMConstSub
U LLVMConstUDiv
U LLVMConstVector
U LLVMContextCreate
U LLVMContextDispose
U LLVMContextSetDiagnosticHandler
U LLVMCopyStringRepOfTargetData
U LLVMCountParams
U LLVMCountParamTypes
U LLVMCountStructElementTypes
U LLVMCreateBuilderInContext
U LLVMCreateDisasm
U LLVMCreateEnumAttribute
U LLVMCreateFunctionPassManagerForModule
U LLVMCreatePassManager
U LLVMCreateTargetData
U LLVMCreateTargetMachine
U LLVMDisasmDispose
U LLVMDisasmInstruction
U LLVMDisposeBuilder
U LLVMDisposeExecutionEngine
U LLVMDisposeMessage
U LLVMDisposeModule
U LLVMDisposePassManager
U LLVMDisposeTargetData
U LLVMDisposeTargetMachine
U LLVMDoubleTypeInContext
U LLVMDumpModule
U LLVMFinalizeFunctionPassManager
U LLVMFloatTypeInContext
U LLVMFunctionType
U LLVMGetAlignment
U LLVMGetArrayLength
U LLVMGetBasicBlockParent
U LLVMGetBasicBlockTerminator
U LLVMGetCalledValue
U LLVMGetDiagInfoDescription
U LLVMGetDiagInfoSeverity
U LLVMGetElementType
U LLVMGetEntryBasicBlock
U LLVMGetEnumAttributeKindForName
U LLVMGetFirstBasicBlock
U LLVMGetFirstFunction
U LLVMGetFirstInstruction
U LLVMGetFunctionCallConv
U LLVMGetGlobalParent
U LLVMGetInsertBlock
U LLVMGetInstructionOpcode
U LLVMGetInstructionParent
U LLVMGetIntrinsicID
U LLVMGetIntTypeWidth
U LLVMGetLastInstruction
U LLVMGetMDKindIDInContext
U LLVMGetModuleContext
U LLVMGetNamedFunction
U LLVMGetNamedGlobal
U LLVMGetNextBasicBlock
U LLVMGetNextFunction
U LLVMGetNextInstruction
U LLVMGetOperand
U LLVMGetParam
U LLVMGetPointerAddressSpace
U LLVMGetPointerToGlobal
U LLVMGetReturnType
U LLVMGetStructElementTypes
U LLVMGetTargetFromTriple
U LLVMGetTypeContext
U LLVMGetTypeKind
U LLVMGetUndef
U LLVMGetValueKind
U LLVMGetValueName
U LLVMGetVectorSize
U LLVMHalfTypeInContext
U LLVMInitializeAMDGPUAsmParser
U LLVMInitializeAMDGPUAsmPrinter
U LLVMInitializeAMDGPUDisassembler
U LLVMInitializeAMDGPUTarget
U LLVMInitializeAMDGPUTargetInfo
U LLVMInitializeAMDGPUTargetMC
U LLVMInitializeFunctionPassManager
U LLVMInitializeX86AsmPrinter
U LLVMInitializeX86Disassembler
U LLVMInitializeX86Target
U LLVMInitializeX86TargetInfo
U LLVMInitializeX86TargetMC
U LLVMInsertBasicBlockInContext
U LLVMInstructionEraseFromParent
U LLVMInt16TypeInContext
U LLVMInt1TypeInContext
U LLVMInt32TypeInContext
U LLVMInt64TypeInContext
U LLVMInt8TypeInContext
U LLVMIntTypeInContext
U LLVMIsAConstantFP
U LLVMIsAFunction
U LLVMIsConstant
U LLVMIsDeclaration
U LLVMIsMultithreaded
U LLVMIsUndef
U LLVMLinkInMCJIT
U LLVMMDNodeInContext
U LLVMModuleCreateWithNameInContext
U LLVMOffsetOfElement
U LLVMParseCommandLineOptions
U LLVMPointerType
U LLVMPositionBuilderAtEnd
U LLVMPositionBuilderBefore
U LLVMPrintModuleToString
U LLVMPrintTypeToString
U LLVMPrintValueToString
U LLVMRunFunctionPassManager
U LLVMRunPassManager
U LLVMSetAlignment
U LLVMSetDataLayout
U LLVMSetFunctionCallConv
U LLVMSetGlobalConstant
U LLVMSetInitializer
U LLVMSetInstructionCallConv
U LLVMSetLinkage
U LLVMSetMetadata
U LLVMSetOperand
U LLVMSetValueName
U LLVMSetVisibility
U LLVMStartMultithreaded
U LLVMStructTypeInContext
U LLVMTokenTypeInContext
U LLVMTypeOf
U LLVMVectorType
U LLVMVerifyFunction
U LLVMVoidTypeInContext
U LLVMWriteBitcodeToFile
U log2
U log2f
U logf
U __longjmp_chk
U lseek64
U malloc
U memchr
U memcmp
U memcpy
U __memcpy_chk
U memmove
U memset
U __memset_chk
U mkdir
U mmap64
U munmap
U newlocale
U open64
U opendir
U open_memstream
U pclose
U perror
U poll
U popen
U posix_memalign
U pow
U powf
U __printf_chk
U __progname_full
U program_invocation_name
U pthread_barrier_destroy
U pthread_barrier_init
U pthread_barrier_wait
U pthread_cond_broadcast
U pthread_cond_destroy
U pthread_cond_init
U pthread_cond_signal
U pthread_cond_timedwait
U pthread_cond_wait
U pthread_create
U pthread_getcpuclockid
U pthread_join
w pthread_mutexattr_destroy
w pthread_mutexattr_init
w pthread_mutexattr_settype
U pthread_mutex_destroy
U pthread_mutex_init
U pthread_mutex_lock
U pthread_mutex_unlock
U pthread_once
U pthread_self
U pthread_setaffinity_np
U pthread_setname_np
U pthread_setschedparam
U pthread_sigmask
U puts
U qsort
U radeon_surface_best
U radeon_surface_init
U radeon_surface_manager_free
U radeon_surface_manager_new
U rand
U read
U readdir64
U realloc
U realpath
U recv
U regcomp
U regexec
U regfree
U rename
U rewind
U scandir64
U sched_getcpu
U sched_yield
U send
U sensors_get_detected_chips
U sensors_get_features
U sensors_get_label
U sensors_get_subfeature
U sensors_get_value
U sensors_init
U sensors_snprintf_chip_name
U setenv
U _setjmp
U setvbuf
U shmat
U shmctl
U shmdt
U shmget
U shutdown
U sigaction
U sigdelset
U sigfillset
U sin
U sincosf
U sinf
U snprintf
U __snprintf_chk
U socket
U __sprintf_chk
U srand
U __stack_chk_fail
U stderr
U stdin
U stdout
U stpcpy
U strcasecmp
U strcat
U strchr
U strchrnul
U strcmp
U strcpy
U __strcpy_chk
U strcspn
U strdup
U strerror
U strlen
U __strncat_chk
U strncmp
U strncpy
U strndup
U strnlen
U strrchr
U strspn
U strstr
U strtod
U strtod_l
U strtof_l
U strtok
U strtok_r
U strtol
U strtoll
U strtoul
U strtoull
U sync
U syscall
U sysconf
U timespec_get
U _ULx86_64_get_proc_info
U _ULx86_64_get_proc_name
U _ULx86_64_get_reg
U _ULx86_64_init_local
U _ULx86_64_step
U uname
U unlink
U _Unwind_Resume
U _Ux86_64_getcontext
U __vasprintf_chk
U __vfprintf_chk
U vsnprintf
U __vsnprintf_chk
U write
U XML_ErrorString
U XML_GetBuffer
U XML_GetCurrentColumnNumber
U XML_GetCurrentLineNumber
U XML_GetErrorCode
U XML_Parse
U XML_ParseBuffer
U XML_ParserCreate
U XML_ParserFree
U XML_SetElementHandler
U XML_SetUserData
U __xstat64
U operator delete[](void*)
U operator delete[](void*, unsigned long)
U operator delete(void*)
U operator delete(void*, unsigned long)
U llvm::DataLayout::clear()
U llvm::DataLayout::~DataLayout()
U llvm::LLVMContext::getOrInsertSyncScopeID(llvm::StringRef)
U llvm::raw_ostream::SetBufferAndMode(char*, unsigned long, llvm::raw_ostream::BufferKind)
U llvm::raw_ostream::~raw_ostream()
U llvm::AtomicRMWInst::AtomicRMWInst(llvm::AtomicRMWInst::BinOp, llvm::Value*, llvm::Value*, llvm::AtomicOrdering, unsigned char, llvm::Instruction*)
U llvm::EngineBuilder::selectTarget()
U llvm::EngineBuilder::setMCJITMemoryManager(std::unique_ptr<llvm::RTDyldMemoryManager, std::default_delete<llvm::RTDyldMemoryManager> >)
U llvm::EngineBuilder::create(llvm::TargetMachine*)
U llvm::EngineBuilder::EngineBuilder(std::unique_ptr<llvm::Module, std::default_delete<llvm::Module> >)
U llvm::EngineBuilder::~EngineBuilder()
U llvm::MCTargetOptions::MCTargetOptions()
U llvm::SmallVectorBase::grow_pod(void*, unsigned long, unsigned long)
U llvm::MetadataTracking::track(void*, llvm::Metadata&, llvm::PointerUnion<llvm::MetadataAsValue*, llvm::Metadata*>)
U llvm::MetadataTracking::retrack(void*, llvm::Metadata&, void*)
U llvm::MetadataTracking::untrack(void*, llvm::Metadata&)
U llvm::AtomicCmpXchgInst::AtomicCmpXchgInst(llvm::Value*, llvm::Value*, llvm::Value*, llvm::AtomicOrdering, llvm::AtomicOrdering, unsigned char, llvm::Instruction*)
U llvm::raw_pwrite_stream::anchor()
U llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
U llvm::RTDyldMemoryManager::anchor()
U llvm::RTDyldMemoryManager::~RTDyldMemoryManager()
U llvm::SectionMemoryManager::SectionMemoryManager(llvm::SectionMemoryManager::MemoryMapper*)
U llvm::createBarrierNoopPass()
U llvm::SymbolTableListTraits<llvm::Instruction>::addNodeToList(llvm::Instruction*)
U llvm::TargetLibraryInfoImpl::TargetLibraryInfoImpl(llvm::Triple const&)
U llvm::report_bad_alloc_error(char const*, bool)
U llvm::LegacyJITSymbolResolver::getResponsibilitySet(std::set<llvm::StringRef, std::less<llvm::StringRef>, std::allocator<llvm::StringRef> > const&)
U llvm::LegacyJITSymbolResolver::lookup(std::set<llvm::StringRef, std::less<llvm::StringRef>, std::allocator<llvm::StringRef> > const&, std::function<void (llvm::Expected<std::map<llvm::StringRef, llvm::JITEvaluatedSymbol, std::less<llvm::StringRef>, std::allocator<std::pair<llvm::StringRef const, llvm::JITEvaluatedSymbol> > > >)>)
U llvm::sys::getHostCPUName()
U llvm::sys::getHostCPUFeatures(llvm::StringMap<bool, llvm::MallocAllocator>&)
U llvm::User::operator delete(void*)
U llvm::User::operator new(unsigned long, unsigned int)
U llvm::Value::setName(llvm::Twine const&)
U llvm::legacy::PassManager::run(llvm::Module&)
U llvm::legacy::PassManager::PassManager()
U llvm::legacy::PassManager::~PassManager()
U llvm::Module::setDataLayout(llvm::DataLayout const&)
U llvm::Module::~Module()
U llvm::Triple::Triple(llvm::Twine const&)
U llvm::Argument::addAttr(llvm::Attribute)
U llvm::Attribute::getWithDereferenceableBytes(llvm::LLVMContext&, unsigned long)
U operator new[](unsigned long)
U llvm::raw_ostream::preferred_buffer_size() const
U llvm::AttributeList::hasAttribute(unsigned int, llvm::Attribute::AttrKind) const
U llvm::Value::getContext() const
U std::ostream& std::ostream::_M_insert<unsigned long>(unsigned long)
U std::ostream& std::ostream::_M_insert<void const*>(void const*)
U std::ostream::operator<<(int)
U std::ostream::operator<<(short)
U std::__basic_file<char>::~__basic_file()
U std::basic_filebuf<char, std::char_traits<char> >::open(char const*, std::_Ios_Openmode)
U std::basic_filebuf<char, std::char_traits<char> >::close()
U std::basic_filebuf<char, std::char_traits<char> >::basic_filebuf()
U std::basic_filebuf<char, std::char_traits<char> >::~basic_filebuf()
U std::basic_ofstream<char, std::char_traits<char> >::basic_ofstream()
U std::basic_ofstream<char, std::char_traits<char> >::~basic_ofstream()
U std::locale::locale()
U std::locale::~locale()
U std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned long, unsigned long, char const*, unsigned long)
U std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_assign(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
U std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long)
U std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_ostringstream()
U std::ios_base::Init::Init()
U std::ios_base::Init::~Init()
U std::ios_base::ios_base()
U std::ios_base::~ios_base()
U std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*)
U std::basic_ios<char, std::char_traits<char> >::clear(std::_Ios_Iostate)
U operator new(unsigned long)
U std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)
U std::__throw_bad_alloc()
U std::__throw_logic_error(char const*)
U std::__throw_length_error(char const*)
U std::cerr
U non-virtual thunk to llvm::RTDyldMemoryManager::anchor()
U typeinfo for llvm::raw_pwrite_stream
U typeinfo for llvm::RTDyldMemoryManager
U VTT for std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >
U VTT for std::basic_ifstream<char, std::char_traits<char> >
U vtable for __cxxabiv1::__class_type_info
U vtable for __cxxabiv1::__si_class_type_info
U vtable for __cxxabiv1::__vmi_class_type_info
U vtable for llvm::raw_pwrite_stream
U vtable for std::__cxx11::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >
U vtable for std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >
U vtable for std::basic_filebuf<char, std::char_traits<char> >
U vtable for std::basic_ifstream<char, std::char_traits<char> >
U vtable for std::basic_streambuf<char, std::char_traits<char> >
U vtable for std::basic_ios<char, std::char_traits<char> >
I'm going to set up a regular amd64 keyworded, no added optimizations system and see if this is the same case. I can't make heads or tails as to why it's so random in what works and what doesn't. Is it really just a case of an upstream's configuration linking -lpthread in the wrong place?
jiblime
on 14 Nov 2019
add '-lm' to LDFLAGS for libomp
perfect7gentleman
on 3 Jun 2020
I'm experiencing the same issue on gcc 10.2.0 with lto. bzip2 broke because of this and I wasn't able to emerge anything. Great story.
GitGangGuy
on 1 Sep 2020
Related issues
ElDavoo
·
5Comments
nivedita76
·
17Comments
nvertigo
·
10Comments
jelinekto
·
11Comments
mid-kid
·
5Comments