[Android] Fix builds with NDK r18 (and possibly later versions when they come) (#12)

This fix is needed to make it possible for Xamarin.Android to switch to Android
NDK r18.

Android NDK r18 dropped GCC from the distribution and the only compiler
available there is clang (currently 7.0.2). For some reason clang has problems
accepting the following calculation of immediate offset in the aes-armv4.S
assembly file (genrated by a perl script):

   sub     r10,r3,#asm_AES_encrypt-AES_Te  @ Te

`asm_AES_encrypt` is the beginning of the assembler routine which implements AES
encryption while `AES_Te` is a beginning of a data table preceeding the
subroutine in the file. GCC appears to have accepted (or encoded differently)
the immediate value resulting from the subtraction, but clang fails with:

   aes-armv4.S:363:2: error: out of range immediate fixup value
       sub r10,r3,#asm_AES_encrypt-AES_Te @ Te

The code in question looks as follow in the assembly file:

   #ifdef  __APPLE__
        adr     r10,AES_Te
   #else
        sub     r10,r3,#asm_AES_encrypt-AES_Te  @ Te
   #endif

The `__APPLE__` macro appears to actually refer to clang, not to macOS, as
suggested by commit message for 672f6fc2486745d0cabc3aaeb4e0a3cd13b37b12:

   [...]
   Instead, use the ADR pseudo-instruction which has clear semantics and
   should be supported by every assembler that handles the OpenSSL Thumb2
   code. (In other files, the ADR vs SUB conditionals are based on
   __thumb2__ already. For some reason, this one is based on __APPLE__, I'm
   guessing to deal with an older version of clang assembler.)

   It's unclear to me which of clang or binutils is "correct" or if this is
   even a well-defined notion beyond "whatever binutils does". But I will
   note that https://github.com/openssl/openssl/pull/4669 suggests binutils
   has also changed behavior around this before.
   [...]

And therefore the workaround proposed by this commit appears to be the right
course of action to fix the NDK r18 build targetting Android.

1 files changed, 17 insertions, 0 deletions

diff --git a/crypto/aes/CMakeLists.txt b/crypto/aes/CMakeLists.txt
index 04705856..7ec24b48 100644
--- a/crypto/aes/CMakeLists.txt
+++ b/crypto/aes/CMakeLists.txt
@@ -1,4 +1,5 @@
 include_directories(../../include)
+option(ENABLE_NDK_ARM_WORKAROUND  "Enable workaround for clang compiler in NDK r18+ failing to compile aes-armv4.S" OFF)
 
 if (${ARCH} STREQUAL "x86_64")
   set(
@@ -29,6 +30,22 @@ if (${ARCH} STREQUAL "arm")
     bsaes-armv7.${ASM_EXT}
     aesv8-armx.${ASM_EXT}
   )
+if (ENABLE_NDK_ARM_WORKAROUND)
+    #
+    # This isn't really *for* Apple, it's for clang in general, but somebody sometime
+    # ago chose to use __APPLE__ because back then clang was used by default only on
+    # macOS. Android NDK r18 and newer dropped gcc and uses only clang, thus the need
+    # to work around the build issue if the symbol is not defined:
+    #
+    #  [...]sdks/builds/android-armeabi-v7a-debug/mono/btls/build-shared/boringssl/crypto/aes/aes-armv4.S:363:2: error: out of range immediate fixup value
+    #       sub r10,r3,#asm_AES_encrypt-AES_Te @ Te
+    #       ^
+    #  [...]sdks/builds/android-armeabi-v7a-debug/mono/btls/build-shared/boringssl/crypto/aes/aes-armv4.S:1010:2: error: out of range immediate fixup value
+    #       sub r10,r3,#asm_AES_decrypt-AES_Td @ Td
+    #       ^
+    #
+    add_definitions(-D__APPLE__)
+  endif()
 endif()
 
 if (${ARCH} STREQUAL "aarch64")