Configurations/*.conf: overhaul Android targets.

        ranlib           => "true",

    },

#### 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-<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-androideabi-

    # PATH=$ANDROID_NDK/toolchains/arm-linux-androideabi-4.8/prebuild/linux-x86_64/bin

    #

    "android" => {

        inherit_from     => [ "linux-generic32" ],

        # 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 is -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           => add("-mandroid -fPIC --sysroot=\$(CROSS_SYSROOT) -Wa,--noexecstack"),

        cxxflags         => add("-mandroid -fPIC --sysroot=\$(CROSS_SYSROOT) -Wa,--noexecstack"),

        bin_cflags       => "-pie",

    },

    "android-x86" => {

        inherit_from     => [ "android", asm("x86_asm") ],

        CFLAGS           => add(picker(release => "-fomit-frame-pointer")),

        bn_ops           => "BN_LLONG",

        perlasm_scheme   => "android",

    },

    ################################################################

    # 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-mips" => {

        inherit_from     => [ "android", asm("mips32_asm") ],

        perlasm_scheme   => "o32",

    },

    "android64" => {

        inherit_from     => [ "linux-generic64" ],

        cflags           => add("-mandroid -fPIC --sysroot=\$(CROSS_SYSROOT) -Wa,--noexecstack"),

        cxxflags         => add("-mandroid -fPIC --sysroot=\$(CROSS_SYSROOT) -Wa,--noexecstack"),

        bin_cflags       => "-pie",

    },

    "android64-aarch64" => {

        inherit_from     => [ "android64", asm("aarch64_asm") ],

        perlasm_scheme   => "linux64",

    },

    "android64-x86_64" => {

        inherit_from     => [ "android64", asm("x86_64_asm") ],

        perlasm_scheme   => "elf",

    },

    "android64-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     => [ "android64", asm("mips64_asm") ],

        perlasm_scheme   => "64",

    },

#### *BSD

    "BSD-generic32" => {

        # As for thread cflag. Idea is to maintain "collective" set of

#### 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" ],

    },

);