I am trying to build the C++ POCO library for an Android target in a fresh Ubuntu that I just installed for that.
I have installed the Android NDK in /home/user/dev/Android/android-ndk-r9-x86
and added the path to the NDK in the environement variables using :
export ANDROID_NDK_ROOT=/home/user/dev/Android/android-ndk-r9-x86
To build the libraries I first move to the root directory of the POCO library, and configure it using :
./configure --omit=NetSSL_OpenSSL,Crypto,Data/ODBC,Data/MySQL --static --config=Android
So that it compiles static .a libraries, doesn't compile the modules I don't want and compiles for an Android target.
But than calling make causes the following error :
user@user-VirtualBox:~/dev/Lib/POCO/poco-1.6.1$ make
make -C /home/user/dev/Lib/POCO/poco-1.6.1/Foundation
make[1]: Entering directory `/home/user/dev/Lib/POCO/poco-1.6.1/Foundation'
** Compiling src/ArchiveStrategy.cpp (debug, static)
arm-linux-androideabi-g++ -Iinclude -I/home/user/dev/Lib/POCO/poco-1.6.1/CppUnit/include -I/home/user/dev/Lib/POCO/poco-1.6.1/CppUnit/WinTestRunner/include -I/home/user/dev/Lib/POCO/poco-1.6.1/Foundation/include -I/home/user/dev/Lib/POCO/poco-1.6.1/XML/include -I/home/user/dev/Lib/POCO/poco-1.6.1/JSON/include -I/home/user/dev/Lib/POCO/poco-1.6.1/Util/include -I/home/user/dev/Lib/POCO/poco-1.6.1/Net/include -mthumb -fpic -ffunction-sections -funwind-tables -fstack-protector -fno-strict-aliasing -finline-limit=64 -frtti -fexceptions -DPOCO_BUILD_HOST=user-VirtualBox -DPOCO_ANDROID -DPOCO_NO_FPENVIRONMENT -DPOCO_NO_WSTRING -DPOCO_NO_SHAREDMEMORY -g -D_DEBUG -c src/ArchiveStrategy.cpp -o /home/user/dev/Lib/POCO/poco-1.6.1/Foundation/obj/Android/armeabi/debug_static/ArchiveStrategy.o
sh: 1: arm-linux-androideabi-g++: not found
make[1]: *** [/home/user/dev/Lib/POCO/poco-1.6.1/Foundation/obj/Android/armeabi/debug_static/ArchiveStrategy.o] Error 127
make[1]: Leaving directory `/home/user/dev/Lib/POCO/poco-1.6.1/Foundation'
make: *** [Foundation-libexec] Error 2
Make seems unable to find the compiler used for Android, and I have no idea why ? What am I missing ? Did i forget something when "installing" the NDK ?
Thank you.
This is often the case with third-party dependencies that are not Android-specific, such as OpenSSL and libbzip2. Build system maintainers looking to add native NDK support to their build systems should instead read the Build System Maintainers Guide. As of NDK r19, the toolchains installed by default with the NDK may be used in-place.
For example, to compile for 64-bit ARM Android with a minSdkVersion of 21, either of the following will work and you may use whichever you find most convenient: In both cases, replace $NDK with the path to the NDK and $HOST_TAG to match the NDK you downloaded according to the following table:
The error you're getting is caused by a missing toolchain invocation - rather, the arm-linux-androideabi-g++ command/executable/binary was nowhere to be found.
Fixed ndk-build script to not overwrite -Os with -O2 for ARM builds. Fixed build scripts to allow overwriting of HOST_AWK, HOST_SED, and HOST_MAKE settings. Fixed issue for ld.gold on fsck_msdos builds linking objects built by the Intel C/C++ compiler (ICC). Fixed ARM EHABI support in Clang to conform to specifications.
The error you're getting is caused by a missing toolchain invocation - rather, the arm-linux-androideabi-g++
command/executable/binary was nowhere to be found.
Luckily, we can get around that by installing the Standalone toolchain - that one actually has the exact thing you're missing, a general purpose arm-linux-androideabi
cross-compiler instead of some other, a bit more obscure, vendor/platform-specific crosscompiler/toolchain, such as armv7a-marvell-linux-android
which is what marvell uses, or arm-linux-android
which is what Clang uses. For more info on Clang, look here. I could be wrong though and that Clang actually produces a arm-linux-androideabi
toolchain out of the box, but I'm unsure. I know you can use it easily, I'm just unsure if it can be used "straight out of the box" which is what you're looking for. The "rest of the work" is just a few path exports - but still. We're aiming for the laziest solution here.
The standalone toolchain should be quite sufficient for your task, so try using it as much as possible over any other cross-compilation solutions.
However, if you're feeling adventurous - you're free to make your own cross-compiler (or the whole toolchain!) using the crosstool-ng
tool. However, try to stick with the Linaro libc branch; personal experience showed me that one somehow works the best and causes the least amount of problems/time wasted.
Also, make sure you download the right one for your architecture (arch) and OS, 32bit vs 64bit matters here as well. After a lengthy discussion, we realized it was a "32bit vs 64bit" problem. Here's a link to read more about it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With