Configurations/10-main.conf: update iOS commentary.

[openssl.git] / Configurations / 10-main.conf

diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf
index 7cd109c7904a1a344027c03a223ac0c30af19808..1d1a212cae3114e8904ad231da50715ccb224e40 100644 (file)
--- a/Configurations/10-main.conf
+++ b/Configurations/10-main.conf
@@ -641,7 +641,7 @@
     "linux-x86_64-clang" => {
         inherit_from     => [ "linux-x86_64" ],
         cc               => "clang",
-        cflags           => "-m64 -DL_ENDIAN -Weverything $clang_disabled_warnings -Qunused-arguments",
+        cflags           => "-m64 -DL_ENDIAN -Wall -Wextra -Qunused-arguments",
     },
     "linux-x32" => {
         inherit_from     => [ "linux-generic32", asm("x86_64_asm") ],
@@ -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" => {
@@ -760,6 +809,18 @@
         perlasm_scheme   => "o32",
     },
 
+    "android64" => {
+        inherit_from     => [ "linux-generic64" ],
+        cflags           => "-mandroid -fPIC --sysroot=\$(CROSS_SYSROOT) -Wa,--noexecstack -Wall",
+        debug_cflags     => "-O0 -g",
+        lflags           => "-pie%-ldl",
+        shared_cflag     => "",
+    },
+    "android64-aarch64" => {
+        inherit_from     => [ "android64", asm("aarch64_asm") ],
+        perlasm_scheme   => "linux64",
+    },
+
 #### *BSD
     "BSD-generic32" => {
         # As for thread_cflag. Idea is to maintain "collective" set of
@@ -1323,6 +1384,15 @@
         cflags           => "-isysroot \$(CROSS_TOP)/SDKs/\$(CROSS_SDK) -fno-common",
         sys_id           => "iOS",
     },
+    "ios-cross" => {
+        inherit_from     => [ "darwin-common", asm("armv4_asm") ],
+        # It should be possible to go below iOS 6 and even add -arch armv6,
+        # thus targeting iPhone pre-3GS, but it's assumed to be irrelevant
+        # at this point.
+        cflags           => "-arch armv7 -mios-version-min=6.0.0 -isysroot \$(CROSS_TOP)/SDKs/\$(CROSS_SDK) -fno-common",
+        sys_id           => "iOS",
+        perlasm_scheme   => "ios32",
+    },
     "ios64-cross" => {
         inherit_from     => [ "darwin-common", asm("aarch64_asm") ],
         cflags           => "-arch arm64 -mios-version-min=7.0.0 -isysroot \$(CROSS_TOP)/SDKs/\$(CROSS_SDK) -fno-common",