build fails on systems where libatomic.so is provided by compiler-rt #39546
Comments
|
@dylanaraps - is there a better way to
Also if you are planning to contribute, here is an example of how to do this in node.gyp in a more natural way: #30099 |
|
It's hard to say. This is rather niche. It's a Linux distribution using LLVM/Clang (and no GNU components; gcc, binutils, etc). The environment can be detected like this:
|
|
With which options do you run the |
./configure \
--shared-zlib \
--shared-openssl \
--with-intl=none \
--without-etw \
--without-dtrace \
--without-report \
--without-node-snapshot \
--without-node-code-cache \
--ninja |
|
Basically, the build system assumes that libatomic is always available on Linux. Problem is that LLVM + compiler-rt can be used to create an environment contrary to this assumption (where libatomic is implicitly provided by compiler-rt). Does this explain things better? Expected behavior would be some kind of detection of this environment (and for the linker flag -latomic to not be passed). |
|
One might ask, how do we detect if There's no good way (aside of |
|
Is there prior art of such detection in other projects? Maybe cpython? |
|
@nodejs/build-files |
|
Hi, I am the packager of nodejs for Gentoo Linux. Thanks, William |
|
Untested, but as libatomic is only needed on some architectures, the diff below probably sidesteps the issue for x86_64: diff --git a/node.gyp b/node.gyp
index 8fe89d8b1bc..12204cb2f60 100644
--- a/node.gyp
+++ b/node.gyp
@@ -115,7 +115,9 @@
'-Wl,-bnoerrmsg',
],
}],
- ['OS == "linux" and llvm_version != "0.0"', {
+ ['OS == "linux" and '
+ 'llvm_version != "0.0" and '
+ 'target_arch in "arm loong64 mips mips64 mips64el mipsel ppc riscv64"', {
'libraries': ['-latomic'],
}],
],LMK if that works for you and I'll turn it into a pull request. |
I just tried it and it still failed with Github has already linked to the ebuild & support files I used to test with, but I am posting the output of |
https://reviews.llvm.org/D85044?id=287068 - looks like compiler-rt does not implement it at the time of writing. Guess that means it's not a drop-in replacement for libatomic yet. |
|
@bnoordhuis @williamh As of this gentoo bug report comment[0], it seems that the problem is resolved and What's the status of this issue now in nodejs? [0] https://bugs.gentoo.org/869992#c13 |
|
I think this can be closed on our end. Thanks for the update. |
|
@bnoordhuis I'm afraid the problem is still not fixed and building with the LLVM toolchain using compiler-rt still requires downstream patching It had been using the patch from #39546 (comment) so far to build
Whether libatomic is needed or not does not (only) depend on the architecture but the toolchain that is used (in my case I use the full/pure LLVM toolchain on x86_64 and riscv64 and don't want libatomic to be linked since it's GCC specific) While looking at the situation I couldn't explain the logic regarding libatomic in
Changing the condition to On # Platforms that don't have Compare-And-Swap (CAS) support need to link atomic library
# to implement atomic memory access
['v8_current_cpu in ["mips64", "mips64el", "ppc", "arm", "riscv64", "loong64"]', {
'link_settings': {
'libraries': ['-latomic', ],
},
}],Using the full LLVM toolchain we don't want/need/can link against libatomic here either. I worked around this by removing |
|
Neither riscv or musl are officially supported targets (i.e. they're self-serve) so you're welcome to send a pull request as long as it doesn't cause regressions on targets that are supported. |
Version
v16.5.0
Platform
Linux desert 5.12.6 #14 SMP Thu Jul 8 23:57:15 EEST 2021 x86_64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
In this environment, no linker flags are needed as compiler-rt provides libatomic implicitly.
The following workaround is used to get builds working:
How often does it reproduce? Is there a required condition?
This is always reproducible in an environment without libatomic (where libatomic is provided by compiler-rt).
What is the expected behavior?
The build succeeds and libatomic is not linked when unneeded.
What do you see instead?
The build attempts to link to libatomic and fails due to the library not existing in the filesystem. The library is provided by compiler-rt in this environment.
Additional information
No response
The text was updated successfully, but these errors were encountered: