cross compile glibc for Android ARM - configure error - android

I am trying to cross-compile glibc (version 2.28) for ARM (because the libc.a distributed with Android NDK lacks the xdr_() routines I need) and I am hitting an issue in the configure.
This is my configure:
../glibc-2.28/configure --prefix=/home/me/TEST --host=arm-linux-androideabi --disable-multilib
The error output by configure is:
GNU libc requires kernel header files from Linux 3.2.0 or later to be
installed before configuring.
It is defaulting to kernel headers in /usr/include/linux. I know I can change where it looks for kernel header files with --with-headers, but don't know where to point this to? I tried apt-get upgrade (and update) but still get the same configure error.
Note 1:
I have already built my arm-linux-androideabi-() binaries successfully and have built other packages OK. I am running on a Linux debian 4.9.0-8-amd64 system.
Note 2:
I checked stackoverflow for similar questions and found one, very similar, but the suggestion was to replace --host with --target. However, the responder was mistaken in thinking that the --host argument defines the machine on which the code is being compiled.

Related

Trying to solve "executable: No such file or directory" when running on Android

I have an executable:
ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked
that runs fine on my machine:
Linux debian 4.19.0-21-amd64 #1 SMP Debian 4.19.249-2 (2022-06-30) x86_64
but fails with
No such file or directory
when run on:
Linux localhost 5.4.61-android11-2-00094-gd61ede24cbb2-ab706444
Question: Do I need to copy over all of the libs that I see when I do:
ldd test.exe
over to the Android device (emulated) to overcome this error? (I'm thinking yes, since it is dynamically linked.). Thanks for any tips here.
Side note: Sort of between a rock and a hard place here since I have read that the LGPL license mandates that if you statically link glibc in your executable you then have to provide all of your source code if you plan to 'publish' your app. Thus, opting for dynamic linking.

Building Qt 5.12 LTS for Android with SSL and SQL support

With google deprecating GCC, Qt 5.12 for Android makes a transition away from it in favor of Clang. Which renders the existing building guides obsolete, as they are all GCC based.
The stock Qt build for Android is lacking some important functionality, and furthermore, the related documentation seems to be fairly outdated.
Additionally, 5.12 launches with a critical Android related bug, which pretty much mandates a custom build to incorporate the fix for the time being.
I myself haven't previously used Clang at all, and I am one of those people who really prefer to just make applications rather than to go through the often excruciatingly frustrating experience of trying to build the requisite tools.
Qt on Clang is here to stay, and 5.12 being a long term support release, I think a detailed step by step guide how to produce a working Qt build will be of benefit to a lot of people. It would definitely save me days of headaches and setbacks, and so I am willing to offer a generous bounty to the first reproducible answer, in addition to any bounties that may be required to promote the question visibility.
My personal requirements are SSL, MySQL and PostgreSQL support, although additional functionality is welcome. It would seem that a Linux based guide will be the most beneficial format, as it is also applicable to windows via MSYS.
I can't reply for all your requests, but I can say something about openssl:
Firstoff, even with Qt 5.12, if you are using the official android builds downloaded from Qt itself (via the Maintenancetool), then you still have to use the gcc toolchain and openssl 1.0.2. The Qt builds require 1.0.* and clang support has only been added to openssl since 1.1.1. Support for this version of openssl will hopefully come with Qt 5.13. See QTBUG-71391 for more details.
That beeing said, if you cross-compile Qt for Android yourself (or visit this post in the future, when Qt supports this), you can use openssl 1.1 and use clang to compile it.
The steps are documented on their github in NOTES.ANDROID. The steps are relatively straight forward and boil down to a few changes to PATH in order to build the library. A basic script, with switches for all android architectures provided by Qt, would be:
TOOLCHAIN_VERSION=4.9
HOST_ARCH=linux-x86_64
case "$ANDROID_TARGET_ARCH" in
arm64-v8a)
API_VERSION=21
ARCH_ID=android-arm64
TOOLCHAIN=aarch64-linux-android-$TOOLCHAIN_VERSION
;;
armeabi-v7a)
API_VERSION=16
ARCH_ID=android-arm
TOOLCHAIN=arm-linux-android-$TOOLCHAIN_VERSION
;;
x86)
API_VERSION=16
ARCH_ID=android-x86
TOOLCHAIN=x86-$TOOLCHAIN_VERSION
;;
*)
echo "Unsupported ANDROID_TARGET_ARCH: $ANDROID_TARGET_ARCH"
exit 1
;;
esac
export ANDROID_NDK=/path/to/ndk
export PATH=$ANDROID_NDK/toolchains/llvm/prebuilt/$HOST_ARCH/bin/:$ANDROID_NDK/toolchains/$TOOLCHAIN/prebuilt/$HOST_ARCH/bin:$PATH
./Configure $ARCH_ID shared no-ssl3 -D__ANDROID_API__=$API_VERSION
make SHLIB_VERSION_NUMBER= SHLIB_EXT=.so build_libs
In this script, ANDROID_TARGET_ARCH is simply the value of the qmake variable with the same name, so this script could be invoked by qmake. The steps that need to be done in detail are:
Prepare some variables:
TOOLCHAIN_VERSION: Simply the version of the gcc toolchain to be used (yes, this is still needed, as some tools, linke ranlib etc. are still used from there). As of NDK v18 the toolchain version is still 4.9
HOST_ARCH: The architecture of the host system. The sample sets this to linux. If you are on window/macos adjust this accordingly.
API_VERSION: The Android SDK version openssl should build for. I set the values to the version that Qt uses for builds for these plattforms, but other versions should be fine as well
ARCH_ID: The name of the android architecture as used by openssl
TOOLCHAIN: The name of the gcc toolchain to be used
Ensure the ANDROID_NDK environment variable is set to wherever you installed the NDK
Update the path to contain both, the clang/llvm toolchain and the gcc toolchain for your specific plattform. In the script, the locations of the toolchains are derived from the previous variables
Explicitly run the Configure script - and not config. Pass the target architecture and additional flags. (I for example prefer to disable ssl3 for security reasons)
Run make to build the library. The SHLIB_VERSION_NUMBER= SHLIB_EXT=.so part is needed to ensure that the binaries created do not have a version number as part of their name, as android does not support that.
And thats it!

"manual" cross-compilation from Linux/x86-64 to Android/ARM?

(Perhaps a border-line question on S.O since I am not showing any source code!)
I want to be able to cross-compile (using the latest GCC trunk, i.e. 4.9) a hello world program in C, compiled on Linux/Debian/Sid/x86-64 for Android (4.4.2 on a rooted Nexus 7), and to be executed in an Android terminal emulator. My goal is to learn how to configure the entire cross-tool chain, probably GCC, binutils, and MUSL libc. So I specifically do not want to use any SDK or NDK for Android!
I guess that my Android is an arm-linux-gnueabi GCC 4.9 primary target platform for GCC & binutils. Is this correct?
Then once I compiled my (statically linked with MUSL libc) hello world, how should I transfer it on the tablet? (MTP probably).
PS. I am quite familiar with Linux (and GCC, to which I contribute, and binutils) but I am a complete Android newbie.
PPS: The real motivation is that I want to compile a plugin for a GCC cross-compiler, preparing a talk about GCC plugins

Compiling Unix tools for android

I want to use some unix tools on my rooted android arm6 based phone. I will be using cross compiler tools provided here. If I want to compile gnu netcat, how can I set the cross compiler prefix to arm-none-linux-gnueabi- and how to enable static linking (no shared library).
I managed to cross-compile rsync for Android using Ubuntu's arm-linux-gnueabi toolchain. See this related question.
Unless you particularly need to build against a more standard libc than bionic, you can just use the ndk's toolchain, either by copying the hello-jni example and changing BUILD_SHARED_LIBRARY to BUILD_EXECUTABLE in the jni/Android.mk or using the script to generate a stand alone toolchain. You may want to use the V=1 option to the ndk-build script to see the commands it's issuing to its gcc.
Otherwise you may need to pass the prefix to the configure script or manually edit it into the Makefile for the project. This often has not gone well as many projects have make systems not really set up for cross compiling, I've had to resort to editing the configure script to set prefixes and skip tests where it tries to execute a test program.
An option that sometimes works when the build system is more complicated than the project requires is to do a configure for your host (let's hope that's linux). Then manually edit the generated Makefile to change anything needed to build for android instead. Might not be a bad idea to do a clean just in case (especially if you did a test host build). And then do the build which will pick up the arm compiler from your Makefile modifications.
Lastly, if you can be content with the original netcat by Hobbit rather than the gnu version, you hardly need to port it to android yourself as that's already been done. There's already an android version in the google tree at https://android.googlesource.com/platform/external/netcat
which may be on your device already (as 'nc'), and is definitely included in alternate ROMs such as Cyanogenmod.

Can the android NDK compile kernel module source?

I want make a dynamic loaded kernel module for android.
I don't want to install a linux, I just have cygwin and android NDK.
Yes, it is possible to build kernel modules with the NDK. Note, this works best with a Linux system (I'm told Linux x86_64 is the supported environment) because it's harder to cross-compile kernel code on case sensitive filesystems (such as those that come by default on Windows and Mac systems), and because building kernel modules requires building ELF-manipulation binaries (modpost) which require ELF headers typically only present on Linux.
That said...
First you need to get the source code to the same exact kernel on your device, and make sure that the configuration is the same as your device. (otherwise there's a chance you will confuse the build system)
Second, you need to determine where in your Android NDK the cross-compiler toolchain is. Here's how I found mine:
$ cd $NDK_HOME
$ find . | grep '\-gcc$'
./toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/bin/arm-eabi-gcc
./toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc
(note, $NDK_HOME is where I installed the Android NDK)
Third, you need to add the $NDK_HOME/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/bin directory (or wherever it is on your system) to your PATH environment variable.
Then you need to export two environment variables:
export ARCH=arm
export CROSS_COMPILE=arm-eabi-
(note, the arm-eabi- prefix is the same as what we saw in the find command. When the kernel is built, commands such as gcc and ld will be prefixed with this. Note, if you were building for an x86 platform I expect you would have to adjust these. I have only built modules for ARM.)
Next, you should compile the kernel. (to do this, I pulled down /proc/config.gz from my Android device, ran zcat config.gz > .config within the kernel source directory, then ran make menuconfig && make.) Kernel build gurus may know some shortcuts here, but I wasn't able to set up the kernel source directory correctly for building a module without doing an actual build. (If the kernel in your build tree matches your device, you don't have to actually update the kernel, you can just insert the modules.)
Last, I used the normal process to build the kernel modules from source. Typically kernel modules will have a parameterized build which will read in the kernel source tree directory somehow, then invoke the build. At that point, as long as the kernel source tree is set up correctly and ARCH and CROSS_COMPILE are set up, your module should build!
Good luck with this. I'm sure there is some per-device variance.
Just now I found this URL where the user has attempted loading LKM and was successful, though on Android (Kernel core: 2.6.29) and I think it was on Linux and not on Cygwin. Hope you get it too!
There is one more resource here and here too!.
All the best!
Follow this URL, Android developer suggests to go for virtual Ubuntu image for this than cygwin.

Categories

Resources