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.
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).
kinke
force-pushed
the
android_tls
branch
4 times, most recently
from
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). |
kinke
changed the title
|
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.