Current libgit2 instructions for Android state the following:
Extract toolchain from NDK using, make-standalone-toolchain.sh script. Optionally, crosscompile and install OpenSSL inside of it. Then create CMake toolchain file that configures paths to your crosscompiler (substitute {PATH} with full path to the toolchain)- https://github.com/libgit2/libgit2
However, it appears that make-standalone-toolchain.sh is now obsolete:
Warning: If using r19 or newer, follow the Use the NDK with other build systems document for instructions on using the NDK toolchains with arbitrary build systems. As of r19, the NDK's default toolchains are standalone toolchains, which renders this process unnecessary. - https://developer.android.com/ndk/guides/standalone_toolchain
Is there a place with updated libgit2 instructions for building it for Android?
Related
I am not a heavy user of rust, so I don't know all of its customs and terminology. I have a project that builds just fine (on a Linux x86_64 host) with Android NDK r21d with cargo, but when I use Android NDK r23b, it fails because binutils has been removed from the NDK:
error occurred: Failed to find tool. Is `aarch64-linux-android-ar` installed?
$ rustc -V
rustc 1.56.1 (59eed8a2a 2021-11-01)
$ cargo -V
cargo 1.56.0 (4ed5d137b 2021-10-04)
I can find Github issues from many months ago for a few projects written in rust that encountered the same or similar problems caused by the removal of binutils.
Do the current versions of rust and cargo simply not support using LLVM's tools (such as llvm-ar) when compiling for Android?
Individual arch *ar binary has been removed from NDK 23+.
To fix copy and rename llvm-ar to aarch64-linux-android-ar in ${ANDROID_NDK_HOME}/toolchains/llvm/prebuilt/{SYSTEM}/bin
OR
set this env var:
AR_aarch64_linux_android=${ANDROID_NDK_HOME}/toolchains/llvm/prebuilt/{SYSTEM}/bin/llvm-ar
Do these for all your target arch.
According to this page I don't need to be using the standalone toolchain anymore. I updated to NDK 20 so this should work for me I thought.
However, as soon as I started to try and recompile my C++ dependencies (ffmpeg at first), I found out aarch64-linux-android-gcc is needed. But this file does not exist anywhere under the $NDK dir (it does exist in the standalone toolchain directory).
So I'm confused, because the impression I got from this
Warning: If using r19 or newer, follow the Other Build Systems document for instructions on using the NDK toolchains with arbitrary build systems. As of r19, the NDK's default toolchains are standalone toolchains, which renders this process unnecessary.
was that I could use the existing toolchain. And my question is: Is that information wrong, should I continue using the standalone toolchain, or am I doing something else wrong?
Standalone toolchains won't help you if your build is using GCC. GCC is no longer supported by the NDK. You need to either (preferably) convert the build to use Clang or (understanding that this means you're going to be struggling with bugs that have since been fixed) downgrade your NDK to a version that supported GCC (r17).
I am trying to build a .so for android and I want to build with address sanitizer but the only instructions I see are for Android NDK based Makefiles, but I am using the newer endorsed CMake setup. Just adding the flag -fsanitize=address wasn't enough as the clang runtime library was missing.
what is the correct thing to add in my CMakeLists for Android built libraries?
You also need to prepare your device as described in documentation. You have to run asan_device_setup script from NDK. It will put asan .so on the device.
What is the path to the ARM cross-compiler in the present distribution of the Android SDK? I am on Mac El Capitan. (I have read many different things all around and I'm a bit confused on how to declare the CROSS_COMPILE variable for compiling the kernel.)
After some investigation, I am now able to answer my own question.
First, the cross-compiler is not part of the SDK, but of the NDK (Native Development Kit). So the first thing to do is fetching (installing) the NDK. I did this easily from Android Studio (which I use just to manage packages).
Second, the toolchain (the stack of tools used to build up a binary) is not there in the NDK directory tree: it has to be extracted. (It is not clear to me yet what this technically means - comments are welcome - what I understand is that the toolchain has to be "created".) To this aim, there is a Python script in the NDK directory tree, namely:
ndk-bundle/build/tools/make_standalone_toolchain.py
Since I am interested in compiling for an ARM architecture, I invoked this by:
./make_standalone_toolchain.py --arch arm --install-dir <desired toolchain location>
At this point, a toolchain is extracted to the <desired toolchain location>, and inside there a cross-compiler may be found.
I'm building gcc for Android on CentOS using the cross-compile toolchain generated by running the make-standalone-toolchain.sh script in the Android NDK, and the gcc source files from the downloaded Android NDK toolchain sources. The GMP sources were obtained by running the download_prerequisites script located in the gcc/contrib folder.
I've specified --build=x86_64-linux and --host=arm-linux-eabi, cross compile tools are set in the env variables, and specified when running configure. I've run ../gcc-4.7/configure, then make -d. Make fails when building gmp with /bin/sh. ./gen-fac_ui. Cannot execute binary.
The specific command is: ./gen-fac_ui $(BITS_PER_MP_LIMB) $(GMP_NAIL_BITS) >mpz/fac_ui.h || (rm -f mpz/fac_ui.h; exit 1)
I'm guessing the execution fails because I'm using cross-compile tools and the gen-fac_ui binary won't run on CentOS. My question is: is there another way to generate mpz/fac_ui.h as a work around?
I've also tried running make -d -i, which finishes successfully but seems to skip building key files...like gcc or g++
Short Answer:
I needed the native (i.e for CentOS) GCC tools to build and run gen-fac_ui.
Long Answer:
This is my post at the OSDev forum, where I basically asked the same question and got an answer. It also contains my error (and correction) of not having glibc-devel installed for the
native GCC toolchain.
In addition, since the base version of GCC for my build system was 4.4.7 and I was trying to cross-native build 4.7, I had to get the developer toolset, which can be installed via yum. Information on the toolset is here and easy install instructions are here
FWIW, I'm still not entirely sure how I was supposed to determine that gen-fac_ui needed to be made by a gcc native to the build machine...other than there was no other way I could find to generate fac_ui.h and other headers.