ld.lld: error: unable to find library -latomic. Reproducible: Always Steps to Reproduce: 1. use musl/clang profile 2. emerge nodejs 3. boom Actual Results: ld.lld: error: unable to find library -latomic clang-14: error: linker command failed with exit code 1 (use -v to see invocation) Expected Results: emerged fine musl/clang on amd64
Created attachment 804979 [details] build.log
Created attachment 804982 [details] emerge--info.txt
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b8ed541d56fe430d8c9d88924de1700db65d37fe commit b8ed541d56fe430d8c9d88924de1700db65d37fe Author: William Hubbs <williamh@gentoo.org> AuthorDate: 2022-09-14 06:11:19 +0000 Commit: William Hubbs <williamh@gentoo.org> CommitDate: 2022-09-14 06:14:20 +0000 net-libs/nodejs: add 18.9.0 Closes: https://github.com/gentoo/gentoo/pull/27242 Bug: https://bugs.gentoo.org/869992 Signed-off-by: William Hubbs <williamh@gentoo.org> net-libs/nodejs/Manifest | 1 + .../files/nodejs-18.9.0-clang-fix-libatomic.patch | 16 ++ net-libs/nodejs/nodejs-18.9.0.ebuild | 246 +++++++++++++++++++++ 3 files changed, 263 insertions(+)
I'm seeing this with nodejs-18.9.0: clang++ -o /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/embedtest -pthread -rdynamic -m64 -Wl,-z,noexecstack -Wl,--whole-archive /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/tools/v8_gypfiles/libv8_snapshot.a -Wl,--no-whole-archive -Wl,-z,relro -Wl,-z,now -O3 -pipe -march=native -Wl,-O1 -Wl,--as-needed -fuse-ld=lld -Wl,--thinlto-jobs=16 -Wl,--build-id=sha1 -Wl,--start-group /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/embedtest/src/node_snapshot_stub.o /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/embedtest/test/embedding/embedtest.o /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/libnode.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/deps/histogram/libhistogram.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/deps/uvwasi/libuvwasi.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/tools/v8_gypfiles/libv8_snapshot.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/tools/v8_gypfiles/libv8_libplatform.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/deps/llhttp/libllhttp.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/deps/base64/libbase64.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/deps/base64/libbase64_ssse3.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/deps/base64/libbase64_sse41.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/deps/base64/libbase64_sse42.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/deps/base64/libbase64_avx.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/deps/base64/libbase64_avx2.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/tools/v8_gypfiles/libv8_base_without_compiler.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/tools/v8_gypfiles/libv8_libbase.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/tools/v8_gypfiles/libv8_zlib.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/tools/v8_gypfiles/libv8_compiler.a /var/tmp/portage/net-libs/nodejs-18.9.0/work/node-v18.9.0/out/Release/obj.target/tools/v8_gypfiles/libv8_initializers.a -lz -luv -lbrotlidec -lbrotlienc -lcares -lnghttp2 -lcrypto -lssl -licui18n -licuuc -licudata -ldl -Wl,--end-group ld.lld: error: undefined symbol: __atomic_is_lock_free >>> referenced by node.cc
(Cc'ing matoro in case interested as it involves append-atomic-flags)
Removing the new patch gets things building here for me on glibc + clang
what would actually be the proper way to solve issues like these? Seems like there is no good way of checking whether you need to link to libatomic or not. Like an upstream change to Clang to ignore "-latomic"? (still kind of ugly) :(.
(In reply to Mike Lothian from comment #6) > Removing the new patch gets things building here for me on glibc + clang It's because we removed linking to libatomic and assumed "append-atomic-flags" in the ebuild would do it correctly.
append-atomic-flags is supposed to do this correctly. Investigating a little bit more now, I tried out the sample code from https://en.cppreference.com/w/c/atomic/atomic_is_lock_free. On my amd64 glibc system, both gcc and clang required -latomic in order to link code using atomic_is_lock_free. In other words, it appears the availability of this function is determined by the libc, not the compiler. My understanding of the situation right now is: glibc/gcc -> NEEDS -latomic glibc/clang -> NEEDS -latomic musl/gcc -> ??? (can somebody test this please?) musl/clang -> needs NO -latomic If this is is the case then the patch should stay in and the ebuild should be changed to depend on the libc rather than using append-atomic-flags with something like: use elibc_glibc && append-libs -latomic
Per discussion in #gentoo-toolchain, adding this here for posterity. This isn't actually an effect of musl vs glibc. It is actually unrelated to glibc/musl, the difference is actually in the compiler support library. sys-libs/compiler-rt completely lacks the __atomic_is_lock_free function, while it is present in libatomic from sys-devel/gcc. This is distinct from the usual __atomic functions which are present in compiler-rt. There is an open PR to add this function in https://reviews.llvm.org/D85044?id=287068. However, until this code is merged in compiler-rt, gcc is REQUIRED to be installed (for its libatomic) in order to build nodejs. Now with default USE, clang will actually pull in gcc's libatomic when passing -latomic. This is changed with USE=default-compiler-rt, which is the condition under which this is broken. The reason I thought it was a musl issue was because this is use.forced under the musl/clang profiles. It actually has nothing to do with the libc. This can be overridden by passing -rtlib=libgcc. I'll open a fixup PR to this effect.
Thanks for explanation!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7dc748f875d8f1a7bda9d0b8c00d45ad4be2d58d commit 7dc748f875d8f1a7bda9d0b8c00d45ad4be2d58d Author: matoro <matoro@users.noreply.github.com> AuthorDate: 2022-09-15 18:46:37 +0000 Commit: William Hubbs <williamh@gentoo.org> CommitDate: 2022-09-16 16:15:16 +0000 net-libs/nodejs: delete libatomic patch + force libgcc as support lib Upstream behavior is correct wrt libatomic (unconditionally adding it) due to their use of atomic_is_lock_free which is yet to be added to compiler-rt (stuck in review hell at https://reviews.llvm.org/D85044). This necessitates forcing libgcc as support lib. Linking to libatomic from gcc is dynamic, so sys-devel/gcc has to go in RDEPEND. Clang can be forced to use libgcc with --rtlib=libgcc, even with USE=default-compiler-rt (which is the original cuase of the bug in question). Closes: https://bugs.gentoo.org/869992 Signed-off-by: William Hubbs <williamh@gentoo.org> .../nodejs/files/nodejs-18.9.0-clang-fix-libatomic.patch | 16 ---------------- net-libs/nodejs/nodejs-18.9.0.ebuild | 10 +++++++--- 2 files changed, 7 insertions(+), 19 deletions(-)
Actually, it seems like __atomic_is_lock_free has been in compiler-rt since v12: https://github.com/llvm/llvm-project/commit/00530dee5d1295dc20ebafdd9a8a79662f41513e The other PR seems to be abandoned in favor of https://reviews.llvm.org/D92302 (merged in v12) Re adding the patch to remove -latomic from node.gyp and changing > `tc-is-clang && append-ldflags "--rtlib=libgcc --unwindlib=libgcc"` back to > `append-atomic-flags compiles, links and runs tests fine for me on an musl+llvm profile (no gcc installed).
(In reply to xbjfk.github from comment #13) > Actually, it seems like __atomic_is_lock_free has been in compiler-rt since > v12: This doesn't explain how the failures occurred with latest Clang (and compiler-rt) versions.
(In reply to Sam James from comment #14) > (In reply to xbjfk.github from comment #13) > > Actually, it seems like __atomic_is_lock_free has been in compiler-rt since > > v12: > > This doesn't explain how the failures occurred with latest Clang (and > compiler-rt) versions. Perhaps they do not use `--rtlib=compiler-rt`? Need to investigate `/etc/clang/*` of such an environment.
At least for bug 870919, toralf's attachments don't have the USE flags for clang-common & friends (newer reports from him should), so you may be right.
Let's carry on in bug 911340.
