Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 869992 - net-libs/nodejs-18.7.0: lld is unable to find libatomic on musl/clang (ld.lld: error: unable to find library -latomic)
Summary: net-libs/nodejs-18.7.0: lld is unable to find libatomic on musl/clang (ld.lld...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: William Hubbs
URL:
Whiteboard:
Keywords: PullRequest
Depends on:
Blocks: systemwide-clang
  Show dependency tree
 
Reported: 2022-09-13 17:31 UTC by Alfred Persson
Modified: 2023-10-01 03:48 UTC (History)
5 users (show)

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


Attachments
build.log (build.log,69.64 KB, text/plain)
2022-09-13 17:32 UTC, Alfred Persson
Details
emerge--info.txt (emerge--info.txt,5.81 KB, text/plain)
2022-09-13 17:34 UTC, Alfred Persson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alfred Persson 2022-09-13 17:31:25 UTC
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
Comment 1 Alfred Persson 2022-09-13 17:32:40 UTC
Created attachment 804979 [details]
build.log
Comment 2 Alfred Persson 2022-09-13 17:34:43 UTC
Created attachment 804982 [details]
emerge--info.txt
Comment 3 Larry the Git Cow gentoo-dev 2022-09-14 06:14:33 UTC
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(+)
Comment 4 Mike Lothian 2022-09-14 09:56:56 UTC
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
Comment 5 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-09-14 10:11:20 UTC
(Cc'ing matoro in case interested as it involves append-atomic-flags)
Comment 6 Mike Lothian 2022-09-14 10:54:20 UTC
Removing the new patch gets things building here for me on glibc + clang
Comment 7 Alfred Persson 2022-09-14 13:30:56 UTC
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) :(.
Comment 8 Alfred Persson 2022-09-14 13:33:11 UTC
(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.
Comment 9 matoro archtester 2022-09-14 14:30:40 UTC
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
Comment 10 matoro archtester 2022-09-14 19:15:38 UTC
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.
Comment 11 Alfred Persson 2022-09-14 19:23:21 UTC
Thanks for explanation!
Comment 12 Larry the Git Cow gentoo-dev 2022-09-16 16:16:18 UTC
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(-)
Comment 13 xbjfk.github 2023-06-16 00:39:23 UTC
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).