| #### Android... |
| # |
| # It takes *one* prior-set environment variable to make it work: |
| # |
| # ANDROID_NDK=/some/where/android-ndk-<ver> |
| # |
| # As well as PATH *adjusted* to cover ${CROSS_COMPILE}gcc and company. |
| # |
| # Note that it's different from original instructions that required to |
| # set CROSS_SYSROOT [to $ANDROID_NDK/platforms/android-<api>/arch-<arch>] |
| # and CROSS_COMPILE. CROSS_SYSROOT is still recognized [and even required |
| # for some legacy targets], but if not set, it's detected and set to the |
| # latest Android platform available with appointed NDK automatically. If |
| # you need to target older platform, pass additional -D__ANDROID_API__=N |
| # to Configure. For example, to compile for ICS on ARM with NDK 10d: |
| # |
| # ANDROID_NDK=/some/where/android-ndk-10d |
| # PATH=$ANDROID_NDK/toolchains/arm-linux-androideabi-4.8/prebuild/linux-x86_64/bin:$PATH |
| # [..]./Configure android-arm -D__ANDROID_API__=14 |
| # |
| # One can engage clang by passing CC=clang to Configure. In such case |
| # PATH needs even more adjustments to cover NDK's clang itself, as well |
| # as unprefixed, yet target-specific ar and ranlib [or not, if you use |
| # binutils-multiarch]. |
| |
| { |
| my $android_ndk = {}; |
| my %triplet = ( |
| arm => "arm-linux-androideabi", |
| arm64 => "aarch64-linux-android", |
| mips => "mipsel-linux-android", |
| mips64 => "mips64el-linux-android", |
| x86 => "i686-linux-android", |
| x86_64 => "x86_64-linux-android", |
| ); |
| |
| sub android_ndk { |
| unless (%$android_ndk) { |
| my $ndk = $ENV{ANDROID_NDK}; |
| die "\$ANDROID_NDK is not defined" if (!$ndk); |
| die "\$ANDROID_NDK=$ndk is invalid" if (!-d "$ndk/platforms"); |
| |
| my $sysroot; |
| |
| if (!($sysroot = $ENV{CROSS_SYSROOT})) { |
| my $api = "*"; |
| |
| # see if user passed -D__ANDROID_API__=N |
| foreach (@{$useradd{CPPDEFINES}}) { |
| if (m|__ANDROID_API__=([0-9]+)|) { |
| $api = $1; |
| last; |
| } |
| } |
| |
| # list available platforms [numerically] |
| my @platforms = sort { $a =~ m/-([0-9]+)$/; my $aa = $1; |
| $b =~ m/-([0-9]+)$/; $aa <=> $1; |
| } glob("$ndk/platforms/android-$api"); |
| die "no $ndk/platforms/android-$api" if ($#platforms < 0); |
| |
| $config{target} =~ m|[^-]+-([^-]+)$|; # split on dash |
| $sysroot = "@platforms[$#platforms]/arch-$1"; |
| } |
| die "no sysroot=$sysroot" if (!-d $sysroot); |
| |
| $sysroot =~ m|/android-([0-9]+)/arch-(\w+)/?$|; |
| my ($api, $arch) = ($1, $2); |
| |
| my $triarch = $triplet{$arch}; |
| my $cflags = "-Wa,--noexecstack"; |
| my $cppflags; |
| |
| # see if user passed CC=clang |
| if ($user{CC} eq "clang") { |
| if (which("clang") !~ m|^$ndk/.*/prebuilt/([^/]+)/|) { |
| die "no NDK clang on \$PATH"; |
| } |
| # harmonize with gcc default |
| (my $tridefault = $triarch) =~ s|^arm-|armv5te-|; |
| $cflags .= " -target $tridefault -gcc-toolchain " |
| . "\$(ANDROID_NDK)/toolchains/$triarch-4.9/prebuilt/$1"; |
| $user{CROSS_COMPILE} = undef; |
| } else { |
| $cflags .= " -mandroid"; |
| $user{CROSS_COMPILE} = "$triarch-"; |
| } |
| |
| if (!-d "$sysroot/usr/include") { |
| my $incroot = "$ndk/sysroot/usr/include"; |
| die "no $incroot" if (!-d $incroot); |
| die "no $incroot/$triarch" if (!-d "$incroot/$triarch"); |
| $incroot =~ s|^$ndk/||; |
| $cppflags = "-D__ANDROID_API__=$api"; |
| $cppflags .= " -isystem \$(ANDROID_NDK)/$incroot/$triarch"; |
| $cppflags .= " -isystem \$(ANDROID_NDK)/$incroot"; |
| } |
| |
| $sysroot =~ s|^$ndk/||; |
| $android_ndk = { |
| cflags => "$cflags --sysroot=\$(ANDROID_NDK)/$sysroot", |
| cppflags => $cppflags, |
| bn_ops => $arch =~ m/64$/ ? "SIXTY_FOUR_BIT_LONG" |
| : "BN_LLONG", |
| }; |
| } |
| |
| return $android_ndk; |
| } |
| } |
| |
| my %targets = ( |
| "android" => { |
| inherit_from => [ "linux-generic32" ], |
| template => 1, |
| ################################################################ |
| # Special note about -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 is -pie. |
| # Older toolchains, e.g. r4, appear to handle it and binaries |
| # turn out 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 => add(sub { android_ndk()->{cflags} }), |
| cppflags => add(sub { android_ndk()->{cppflags} }), |
| cxxflags => add(sub { android_ndk()->{cflags} }), |
| bn_ops => sub { android_ndk()->{bn_ops} }, |
| bin_cflags => "-pie", |
| }, |
| "android-arm" => { |
| ################################################################ |
| # 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-arm -D__ARM_MAX_ARCH__=8 |
| # |
| # in order to build "universal" binary and allow OpenSSL take |
| # advantage of NEON when it's available. |
| # |
| # Keep in mind that [just like with linux-armv4] we rely on |
| # compiler defaults, which is not necessarily what you had |
| # in mind, in which case you would have to pass additional |
| # -march and/or -mfloat-abi flags. NDK defaults to armv5te. |
| # |
| inherit_from => [ "android", asm("armv4_asm") ], |
| }, |
| "android-arm64" => { |
| inherit_from => [ "android", asm("aarch64_asm") ], |
| perlasm_scheme => "linux64", |
| }, |
| |
| "android-mips" => { |
| inherit_from => [ "android", asm("mips32_asm") ], |
| perlasm_scheme => "o32", |
| }, |
| "android-mips64" => { |
| ################################################################ |
| # You are more than likely have to specify target processor |
| # on ./Configure command line. Trouble is that toolchain's |
| # default is MIPS64r6 (at least in r10d), but there are no |
| # such processors around (or they are too rare to spot one). |
| # Actual problem is that MIPS64r6 is binary incompatible |
| # with previous MIPS ISA versions, in sense that unlike |
| # prior versions original MIPS binary code will fail. |
| # |
| inherit_from => [ "android", asm("mips64_asm") ], |
| perlasm_scheme => "64", |
| }, |
| |
| "android-x86" => { |
| inherit_from => [ "android", asm("x86_asm") ], |
| CFLAGS => add(picker(release => "-fomit-frame-pointer")), |
| bn_ops => add("RC4_INT"), |
| perlasm_scheme => "android", |
| }, |
| "android-x86_64" => { |
| inherit_from => [ "android", asm("x86_64_asm") ], |
| bn_ops => add("RC4_INT"), |
| perlasm_scheme => "elf", |
| }, |
| |
| #################################################################### |
| # Backward compatible targets, [might] requre $CROSS_SYSROOT |
| # |
| "android-armeabi" => { |
| inherit_from => [ "android-arm" ], |
| }, |
| "android64" => { |
| inherit_from => [ "android" ], |
| }, |
| "android64-aarch64" => { |
| inherit_from => [ "android-arm64" ], |
| }, |
| "android64-x86_64" => { |
| inherit_from => [ "android-x86_64" ], |
| }, |
| "android64-mips64" => { |
| inherit_from => [ "android-mips64" ], |
| }, |
| ); |
