2018-03-16 11:14:28 +00:00
|
|
|
|
|
|
|
NOTES FOR ANDROID PLATFORMS
|
|
|
|
===========================
|
|
|
|
|
|
|
|
Requirement details
|
|
|
|
-------------------
|
|
|
|
|
|
|
|
Beside basic tools like perl and make you'll need to download the Android
|
|
|
|
NDK. It's available for Linux, Mac OS X and Windows, but only Linux
|
|
|
|
version was actually tested. There is no reason to believe that Mac OS X
|
|
|
|
wouldn't work. And as for Windows, it's unclear which "shell" would be
|
|
|
|
suitable, MSYS2 might have best chances. NDK version should play lesser
|
|
|
|
role, the goal is to support a range of most recent versions.
|
|
|
|
|
|
|
|
Configuration
|
|
|
|
-------------
|
|
|
|
|
|
|
|
Android is naturally cross-compiled target and you can't use ./config.
|
|
|
|
You have to use ./Configure and name your target explicitly; there are
|
|
|
|
android-arm, android-arm64, android-mips, android-mip64, android-x86
|
|
|
|
and android-x86_64. Do not pass --cross-compile-prefix (as you might
|
|
|
|
be tempted), as it will be "calculated" automatically based on chosen
|
|
|
|
platform. Though you still need to know the prefix to extend your PATH,
|
|
|
|
in order to invoke $(CROSS_COMPILE)gcc and company. (Configure will fail
|
|
|
|
and give you a hint if you get it wrong.) Apart from PATH adjustment
|
|
|
|
you need to set ANDROID_NDK environment to point at NDK directory
|
2018-10-14 13:19:41 +00:00
|
|
|
as /some/where/android-ndk-<ver>. Both variables are significant at both
|
|
|
|
configuration and compilation times. NDK customarily supports multiple
|
2018-03-16 11:14:28 +00:00
|
|
|
Android API levels, e.g. android-14, android-21, etc. By default latest
|
|
|
|
one available is chosen. If you need to target older platform, pass
|
|
|
|
additional -D__ANDROID_API__=N to Configure. N is numeric value of the
|
|
|
|
target platform version. For example, to compile for ICS on ARM with
|
|
|
|
NDK 10d:
|
|
|
|
|
2018-10-14 13:19:41 +00:00
|
|
|
export ANDROID_NDK=/some/where/android-ndk-10d
|
2018-05-13 17:51:52 +00:00
|
|
|
PATH=$ANDROID_NDK/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin:$PATH
|
2018-03-16 11:14:28 +00:00
|
|
|
./Configure android-arm -D__ANDROID_API__=14
|
2018-10-14 13:19:41 +00:00
|
|
|
make
|
2018-03-16 11:14:28 +00:00
|
|
|
|
|
|
|
Caveat lector! Earlier OpenSSL versions relied on additional CROSS_SYSROOT
|
|
|
|
variable set to $ANDROID_NDK/platforms/android-<api>/arch-<arch> to
|
|
|
|
appoint headers-n-libraries' location. It's still recognized in order
|
|
|
|
to facilitate migration from older projects. However, since API level
|
|
|
|
appears in CROSS_SYSROOT value, passing -D__ANDROID_API__=N can be in
|
|
|
|
conflict, and mixing the two is therefore not supported. Migration to
|
|
|
|
CROSS_SYSROOT-less setup is recommended.
|
|
|
|
|
2018-10-14 13:19:41 +00:00
|
|
|
One can engage clang by adjusting PATH to cover same NDK's clang. Just
|
|
|
|
keep in mind that if you miss it, Configure will try to use gcc...
|
|
|
|
Also, PATH would need even further adjustment to cover unprefixed, yet
|
2018-08-06 07:43:39 +00:00
|
|
|
target-specific, ar and ranlib. It's possible that you don't need to
|
|
|
|
bother, if binutils-multiarch is installed on your Linux system.
|
2018-03-16 11:14:28 +00:00
|
|
|
|
2018-10-14 13:19:41 +00:00
|
|
|
Another option is to create so called "standalone toolchain" tailored
|
|
|
|
for single specific platform including Android API level, and assign its
|
|
|
|
location to ANDROID_NDK. In such case you have to pass matching target
|
2019-01-22 02:14:34 +00:00
|
|
|
name to Configure and shouldn't use -D__ANDROID_API__=N. PATH adjustment
|
2018-10-14 13:19:41 +00:00
|
|
|
becomes simpler, $ANDROID_NDK/bin:$PATH suffices.
|
|
|
|
|
2018-03-16 11:14:28 +00:00
|
|
|
Running tests (on Linux)
|
|
|
|
------------------------
|
|
|
|
|
|
|
|
This is not actually supported. Notes are meant rather as inspiration.
|
|
|
|
|
|
|
|
Even though build output targets alien system, it's possible to execute
|
|
|
|
test suite on Linux system by employing qemu-user. The trick is static
|
|
|
|
linking. Pass -static to Configure, then edit generated Makefile and
|
|
|
|
remove occurrences of -ldl and -pie flags. You would also need to pick
|
|
|
|
API version that comes with usable static libraries, 42/2=21 used to
|
|
|
|
work. Once built, you should be able to
|
|
|
|
|
|
|
|
env EXE_SHELL=qemu-<arch> make test
|
|
|
|
|
|
|
|
If you need to pass additional flag to qemu, quotes are your friend, e.g.
|
|
|
|
|
|
|
|
env EXE_SHELL="qemu-mips64el -cpu MIPS64R6-generic" make test
|