diff options
author | Andy Polyakov <appro@openssl.org> | 2015-03-30 16:47:57 +0200 |
---|---|---|
committer | Andy Polyakov <appro@openssl.org> | 2015-04-02 09:36:32 +0200 |
commit | 449e3f2601246e533a05ccf227375c1e15db2b55 (patch) | |
tree | b126c6965f119cbcef4b6a4daef9e8d398b7531a /Configurations | |
parent | 11305038e904cdebd1c8882f6f508fe0dd14e349 (diff) | |
download | openssl-449e3f2601246e533a05ccf227375c1e15db2b55.zip openssl-449e3f2601246e533a05ccf227375c1e15db2b55.tar.gz openssl-449e3f2601246e533a05ccf227375c1e15db2b55.tar.bz2 |
Configure: android-arm facelift.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Diffstat (limited to 'Configurations')
-rw-r--r-- | Configurations/10-main.conf | 53 |
1 files changed, 51 insertions, 2 deletions
diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index 7cd109c..ab269ba 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -740,10 +740,35 @@ }, #### Android: linux-* but without pointers to headers and libs. + # + # It takes pair of prior-set environment variables to make it work: + # + # CROSS_SYSROOT=/some/where/android-ndk-<ver>/platforms/android-<apiver>/arch-< + # CROSS_COMPILE=<prefix> + # + # As well as PATH adjusted to cover ${CROSS_COMPILE}gcc and company. + # For example to compile for ICS and ARM with NDK 10d, you'd: + # + # ANDROID_NDK=/some/where/android-ndk-10d + # CROSS_SYSROOT=$ANDROID_NDK/platforms/android-14/arch-arm + # CROSS_COMPILE=arm-linux-adroideabi- + # PATH=$ANDROID_NDK/toolchains/arm-linux-androideabi-4.8/prebuild/linux-x86_64/ + # "android" => { inherit_from => [ "linux-generic32" ], - cflags => "-mandroid -I\$(ANDROID_DEV)/include -B\$(ANDROID_DEV)/lib -Wall", + # Special note about unconditional -fPIC and -pie. The underlying + # reason is that Lollipop refuses to run non-PIE. But what about + # older systems and NDKs? -fPIC was never problem, so the only + # concern if -pie. Older toolchains, e.g. r4, appear to handle it + # and binaries turn mostly functional. "Mostly" means that oldest + # Androids, such as Froyo, fail to handle executable, but newer + # systems are perfectly capable of executing binaries targeting + # Froyo. Keep in mind that in the nutshell Android builds are + # about JNI, i.e. shared libraries, not applications. + cflags => "-mandroid -fPIC --sysroot=\$(CROSS_SYSROOT) -Wa,--noexecstack -Wall", debug_cflags => "-O0 -g", + lflags => "-pie%-ldl", + shared_cflag => "", }, "android-x86" => { inherit_from => [ "android", asm("x86_asm") ], @@ -751,8 +776,32 @@ bn_ops => "BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}", perlasm_scheme => "android", }, - "android-armv7" => { + ################################################################ + # Contemporary Android applications can provide multiple JNI + # providers in .apk, targeting multiple architectures. Among + # them there is "place" for two ARM flavours: generic eabi and + # armv7-a/hard-float. However, it should be noted that OpenSSL's + # ability to engage NEON is not constrained by ABI choice, nor + # is your ability to call OpenSSL from your application code + # compiled with floating-point ABI other than default 'soft'. + # [Latter thanks to __attribute__((pcs("aapcs"))) declaration.] + # This means that choice of ARM libraries you provide in .apk + # is driven by application needs. For example if application + # itself benefits from NEON or is floating-point intensive, then + # it might be appropriate to provide both libraries. Otherwise + # just generic eabi would do. But in latter case it would be + # appropriate to + # + # ./Configure android-armeabi -D__ARM_MAX_ARCH__=8 + # + # in order to build "universal" binary and allow OpenSSL take + # advantage of NEON when it's available. + # + "android-armeabi" => { inherit_from => [ "android", asm("armv4_asm") ], + }, + "android-armv7" => { + inherit_from => [ "android-armeabi" ], cflags => sub { join (" ","-march=armv7-a",@_); }, }, "android-mips" => { |