Configurations/*.conf: overhaul Android targets.

Move Android targets to separate file, automate sysroot setup and
add support for NDK 16.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5589)

1 files changed, 0 insertions, 93 deletions

diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf
index 0407a812ec..1ba7cb829b 100644
--- a/Configurations/10-main.conf
+++ b/Configurations/10-main.conf
@@ -940,99 +940,6 @@ my %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