Skip to content

Lib atomic is linked dynamically for i686-linux-android target #2163

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
Maximkaaa opened this issue Feb 8, 2024 · 4 comments
Open

Lib atomic is linked dynamically for i686-linux-android target #2163

Maximkaaa opened this issue Feb 8, 2024 · 4 comments

Comments

@Maximkaaa
Copy link

As stated in the title, when compiling for x86 android target, there are these symbols exported in the compiled binary:

         U __atomic_fetch_or_8
         U __atomic_is_lock_free
         U __atomic_load

This is related to #2043, but it seems that the fix in #2094 doesn't work for all targets. When using openssl-sys = "=0.9.92", libatomic is linked statically and these symbols are not exported. So this seems like a regression in v0.9.93.

I've checked other android targets (x86_64-linux-android, armv7-linux-androidabi, aarch64-linux-android), and for them the lib is linked statically.

@rami3l
Copy link

rami3l commented Feb 13, 2024

This seems to be preventing a new Rustup release from happening (rust-lang/rustup#3668).

Currently the CI fails on the i686-linux-android target with the following error:

  = note: ld: error: undefined symbol: __atomic_is_lock_free
          >>> referenced by threads_pthread.c:227 (crypto/threads_pthread.c:227)
          >>>               libcrypto-lib-threads_pthread.o:(CRYPTO_atomic_or) in archive /checkout/target/i686-linux-android/debug/deps/libopenssl_sys-1848ac406e42211b.rlib
          >>> referenced by threads_pthread.c:252 (crypto/threads_pthread.c:252)
          >>>               libcrypto-lib-threads_pthread.o:(CRYPTO_atomic_load) in archive /checkout/target/i686-linux-android/debug/deps/libopenssl_sys-1848ac406e42211b.rlib
          
          ld: error: undefined symbol: __atomic_fetch_or_8
          >>> referenced by threads_pthread.c:228 (crypto/threads_pthread.c:228)
          >>>               libcrypto-lib-threads_pthread.o:(CRYPTO_atomic_or) in archive /checkout/target/i686-linux-android/debug/deps/libopenssl_sys-1848ac406e42211b.rlib
          
          ld: error: undefined symbol: __atomic_load
          >>> referenced by threads_pthread.c:253 (crypto/threads_pthread.c:253)
          >>>               libcrypto-lib-threads_pthread.o:(CRYPTO_atomic_load) in archive /checkout/target/i686-linux-android/debug/deps/libopenssl_sys-1848ac406e42211b.rlib
          clang-14: error: linker command failed with exit code 1 (use -v to see invocation)

... which matches the observations above.

My guess is that we should keep #2094 but make a special case for Android i686 like in rusqlite/rusqlite#1037. I'm still experimenting the build with rustup itself and will come back later if I've found a fix.

I guess one way forward is to add -DBROKEN_CLANG_ATOMICS (openssl/openssl#20687 (comment), https://github.com/macports/macports-ports/blob/f543051794963064ea924697f7a33428936fbe2a/devel/openssl3/Portfile#L132-L136) just for Android i686 but that does not like a really good solution in general...

I'll let the maintainers decide then.

@elpiel
Copy link

elpiel commented Nov 6, 2024

I want to ping this issue as we also encountered this issue.
Our TV app uses 64bit version but the recommended emulator is 32 bit and I think it needs a higher priority to be fixed due to the integration with Android Studio and the emulator.

Thanks in advance!

PS: I'd love to submit a PR but not sure how this should be resolved on for the i686-linux-android target

@juanky201271
Copy link

some update over here? Thanks in advance.

@weihanglo
Copy link

FWIW, In Cargo we did some investigations and it seems to be a bug in the upstream OpenSSL: rust-lang/cargo#13546 (comment). We accepted the current situation and consider libatomic as a hard requirement, until OpenSSL fixes the issue.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants