-
-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Android: Switch to native ELF TLS & latest LTS NDK, and enable shared druntime/Phobos #4618
Conversation
@s-ludwig @PetarKirov: Would you happen to be able and willing to check out the CI artifacts from https://github.com/ldc-developers/ldc/actions/runs/8676824079?pr=4618? E.g., if the bundled dub executable works fine to build some little app natively on Android, I'd expect things to be good (enough TLS coverage in dub and compiler itself). If this works, we could most likely simply enable shared druntime+Phobos support for Android too, i.e., including the shared .so libs and allowing multiple D binaries in a single process, just like on vanilla Linux. |
arch='${{ inputs.arch }}' | ||
apiLevel='${{ inputs.android_api_level }}' | ||
cmakeFlags="-DTARGET_SYSTEM='Android;Linux;UNIX'" | ||
if [[ "$arch" == armv7a ]]; then | ||
triple="$arch-linux-androideabi$apiLevel" | ||
cmakeFlags+=' -DANDROID_ABI=armeabi-v7a' | ||
elif [[ "$arch" == aarch64 ]]; then | ||
# FIXME: as of NDK rc26d, libc.a has __tls_get_addr, but libc.so only since API level 30 (Android v11) | ||
apiLevel=30 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit weird that the AArch64 libc.so
got the required __tls_get_addr
symbol in level 30, not level 29 as for armv7a; the NDK changelog doesn't mention this. Not sure whether this is an oversight in the NDK (it's like this for r26c and r26d), or whether there's a good reason why __tls_get_addr
requires Android v11+ on AArch64 (unless linking libc statically).
5815927
to
30d0447
Compare
We've performed a quick test with a newly built runtime for NDK 25 and while it built successfully, for some reason it now hangs in a |
THx for checking. So you haven't tested the prebuilt libs, but built them yourself? Using a prebuilt compiler here, or some other existing compiler? The former is required, as the main change is in the used LLVM (not visible in this diff here). |
I've used the compiler binary from the linux-x86_64 CI build, but generating an android runtime since none is included there. Should I try again using the libraries from the android-aarch64 build? |
Might be worth a try, but I wouldn't expect wonders. Ideally with the same NDK r26d? - No idea how you built the libs exactly; I've dropped the Some TLS malfunction resulting in a hanging libcrypto init sounds a bit weird/unlucky though IMO... |
Shall we get this in for beta1 to gather more feedback, reverting it for the final if problematic? |
I've just tested again, this time with the latest CI artifacts, using the compiler binary from the linux-x86_64 artifact and the libraries from the android-aarch64 artifact, using NDK 26.3.11579264. Unfortunately, this results in exactly the same hang. I can try to generate a more minimal JNI library and specifically test TLS to hopefully narrow this down a bit. |
Okay thx for testing & trying. How's that libcrypto built? I've had a extremely quick look into the repo, grepping for |
Okay, basic TLS seems to work fine (setting an integer TLS variable, starting a setting/manipulating the same variable concurrently). |
Turned out the libcrypto was still built against NDK 25 due to a CI misconfiguration. Rebuilt against NDK 26 and now works flawlessly! |
Oh wow, awesome news, thx! |
Fixes #3918.