Arm and libatomic #3092
Labels
bug report
Something is not working properly
Comments
|
This might be of your interest: The only difference of the linking commands issued (manually) is the position of |
|
Interesting, so we should perhaps patch llvm (and try not to break anything else)? I wonder if any of the LDFLAGS linking we do in various packages can be fixed in the same way.. |
|
Not really sure tbh. Just happen to have bumped into similar problem and noticed the weird positioning of the link flags. I have been curious why clang/ld would only link to libgcc but not libatomic by default as well. Though apparently when on aarch64, libatomic is not needed (for this) at all (like, it builds even if I have the file deleted). (Does it hurt / make a difference to link to a static library that is not used though.) |
|
Here's a comment in the NDK repo which says that the linking order is important, as you have shown: android/ndk#589 (comment). I also think I read some discussion about -latomic being needed on 32bit arches but not 64bit but can't fins it now. I did find this comment in the ndk r16 changelog that -latomic shouldn't be needed anymore: https://github.com/android-ndk/ndk/wiki/Changelog-r16#ndk |
|
A quick hack to this is add -u __atomic_load_4 -latomic to ldflags but that comes with downsides since it might increase size of all libs and executables unnecessarily, |
|
@its-pointless Yes, that works! Both The mentioned cmake test in |
Akianonymus
added a commit
to Akianonymus/gitstatus
that referenced
this issue
Jan 18, 2020
romkatv
pushed a commit
to romkatv/gitstatus
that referenced
this issue
Mar 30, 2020
Merged
|
This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
With clang 13, and libc++ from ndk-r23, this does not seem to be a problem anymore |
thunder-coding
added a commit
that referenced
this issue
Dec 1, 2021
Additional changes made: - The patch `deps-v8-src-trap-handler-trap-handler.h.patch` should no longer be needed needed. This should also have been fixed nodejs/node#36287. If this PR succeeds to build, I will report that this has been fixed by nodejs/node@e3f8988#diff-f350b1b5e53caf9ecde4240ba8f544b3be4f278e4f8efa86b54c30ea625b8b1d - The libatomic hack has been removed since #3092 has been reported to have been fixed with newer NDK
Merged
thunder-coding
added a commit
that referenced
this issue
Dec 1, 2021
Additional changes made: - The libatomic hack has been removed since #3092 has been reported to have been fixed with newer NDK
thunder-coding
added a commit
that referenced
this issue
Dec 2, 2021
Additional changes made: - The libatomic hack has been removed since #3092 has been reported to have been fixed with newer NDK
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider this code:
Which is taken from cmake's
$PREFIX/lib/cmake/llvm/CheckCompilerVersion.cmakeand used for checking for libstdc++4.8 or newer. When compiling this on arm withclang++ tmp.cppI getWe get the same error for some i686 (and arm?) packages when cross-compiling, but there it can be solved with
-latomic. Compiling on device withclang++ -latomic tmp.cpphas no effect though, it gives the same error message.I suppose this is due to the difference between android's linker and the standard gnu/Linux linker, and we can solve this by linking one of llvm/clang's libraries against libatomic.a. But which one?
The text was updated successfully, but these errors were encountered: