Compiling and running dynamically-linked 32-bit ARM binaries on aarch64

[rrthomas]

I would like to compile and run 32-bit dynamically linked ARM binaries on aarch64. (I'm using termux on Android 9).

I found #1258, which nearly gets me all the way there. The only thing that is missing is that its recipe requires the required libraries to be copied over $PREFIX/lib, e.g.:

$ cp $PREFIX/arm-linux-androideabi/lib/* $PREFIX/lib/
$ clang -m32 test.c -L/system/lib -Wl,-rpath-link=/system/lib

I would prefer not to have to copy the libraries around, as presumably that in any case prevents me from running 64-bit binaries while I have the 32-bit libraries in place?

Whatever I do without this step, if I build a 32-bit binary, I get a segfault when I try to run it.

I was able to workaround this by building with -static, but it would be nice not to have to do this.

So far I can:

$ unset LD_PRELOAD
$ clang -m32 -static foo.c
$ ./a.out
hello, world!

But if I remove -static I just get a segfault. If I add the -L and -Wl flags from the recipe above, it doesn't work either. I have ndk-multilib installed. Sorry if I'm missing something obvious!

clang --target=armv7-linux-androideabi -fuse-ld=lld.
Don't use -m32. Copying libs is not needed too.

[rrthomas]

@xeffyr, thanks very much for getting back to me. I tried the flags you suggested and when I run the resultant binary I get a bus error (rather than a segfault as before).

when I run the resultant binary I get a bus error

Probably due to incompatibility between your system linker (/system/bin/linker) and libc.so from ndk-sysroot.

[rrthomas]

Ah, OK. So is there anything I can do, or do I have to stick to static linking?

Thanks again for your help!

[finagolfin]

I have gotten fairly large 32-bit binaries to run this way before, after doing unset LD_PRELOAD. Check readelf -d on the binary and make sure the runpath is set properly. You shouldn't have to specify /system/lib either, maybe that's why he thinks your system's dynamic linker is broken.

[finagolfin]

Alright, I'm able to reproduce this: the problem appears to be fbc8e9e, which unnecessarily copies the ARMv7 lib{c,m,dl}.{so,a} into the Termux prefix, despite their already being there in /system/lib. This causes various linker problems.

@rrthomas, you can confirm this with the following command before compiling again, mv $PREFIX/arm-linux-androideabi/lib/lib{c,dl,m,log}.{so,a} $PREFIX/arm-linux-androideabi/. That gets the ndk-multilib versions of those libraries out of the way and uses the /system/lib versions again.

That commit is useful if you want to cross-compile from aarch64 to x86_64 or something, but maybe it shouldn't be done for ARMv7 and x86 for the AArch64 and x86_64 versions of the ndk-multilib package.