| 
									
										
										
										
											2018-03-16 19:14:28 +08:00
										 |  |  | 
 | 
					
						
							|  |  |  |  NOTES FOR ANDROID PLATFORMS | 
					
						
							|  |  |  |  =========================== | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |  Requirement details | 
					
						
							|  |  |  |  ------------------- | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |  Beside basic tools like perl and make you'll need to download the Android | 
					
						
							|  |  |  |  NDK. It's available for Linux, Mac OS X and Windows, but only Linux | 
					
						
							|  |  |  |  version was actually tested. There is no reason to believe that Mac OS X | 
					
						
							|  |  |  |  wouldn't work. And as for Windows, it's unclear which "shell" would be | 
					
						
							|  |  |  |  suitable, MSYS2 might have best chances. NDK version should play lesser | 
					
						
							|  |  |  |  role, the goal is to support a range of most recent versions. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |  Configuration | 
					
						
							|  |  |  |  ------------- | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |  Android is naturally cross-compiled target and you can't use ./config. | 
					
						
							|  |  |  |  You have to use ./Configure and name your target explicitly; there are | 
					
						
							|  |  |  |  android-arm, android-arm64, android-mips, android-mip64, android-x86 | 
					
						
							|  |  |  |  and android-x86_64. Do not pass --cross-compile-prefix (as you might | 
					
						
							|  |  |  |  be tempted), as it will be "calculated" automatically based on chosen | 
					
						
							|  |  |  |  platform. Though you still need to know the prefix to extend your PATH, | 
					
						
							|  |  |  |  in order to invoke $(CROSS_COMPILE)gcc and company. (Configure will fail | 
					
						
							|  |  |  |  and give you a hint if you get it wrong.) Apart from PATH adjustment | 
					
						
							|  |  |  |  you need to set ANDROID_NDK environment to point at NDK directory | 
					
						
							|  |  |  |  as /some/where/android-ndk-<ver>. NDK customarily supports multiple | 
					
						
							|  |  |  |  Android API levels, e.g. android-14, android-21, etc. By default latest  | 
					
						
							|  |  |  |  one available is chosen. If you need to target older platform, pass | 
					
						
							|  |  |  |  additional -D__ANDROID_API__=N to Configure. N is numeric value of the | 
					
						
							|  |  |  |  target platform version. For example, to compile for ICS on ARM with | 
					
						
							|  |  |  |  NDK 10d: | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |     ANDROID_NDK=/some/where/android-ndk-10d | 
					
						
							| 
									
										
										
										
											2018-05-14 01:51:52 +08:00
										 |  |  |     PATH=$ANDROID_NDK/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin:$PATH | 
					
						
							| 
									
										
										
										
											2018-03-16 19:14:28 +08:00
										 |  |  |     ./Configure android-arm -D__ANDROID_API__=14 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |  Caveat lector! Earlier OpenSSL versions relied on additional CROSS_SYSROOT | 
					
						
							|  |  |  |  variable set to $ANDROID_NDK/platforms/android-<api>/arch-<arch> to | 
					
						
							|  |  |  |  appoint headers-n-libraries' location. It's still recognized in order | 
					
						
							|  |  |  |  to facilitate migration from older projects. However, since API level | 
					
						
							|  |  |  |  appears in CROSS_SYSROOT value, passing -D__ANDROID_API__=N can be in | 
					
						
							|  |  |  |  conflict, and mixing the two is therefore not supported. Migration to | 
					
						
							|  |  |  |  CROSS_SYSROOT-less setup is recommended. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2018-03-17 17:59:57 +08:00
										 |  |  |  One can engage clang by adjusting PATH to cover NDK's clang. Just keep | 
					
						
							|  |  |  |  in mind that if you miss it, Configure will try to use gcc... Also, | 
					
						
							|  |  |  |  PATH would need even further adjustment to cover unprefixed, yet | 
					
						
							| 
									
										
										
										
											2018-08-06 15:43:39 +08:00
										 |  |  |  target-specific, ar and ranlib. It's possible that you don't need to | 
					
						
							|  |  |  |  bother, if binutils-multiarch is installed on your Linux system. | 
					
						
							| 
									
										
										
										
											2018-03-16 19:14:28 +08:00
										 |  |  | 
 | 
					
						
							|  |  |  |  Running tests (on Linux) | 
					
						
							|  |  |  |  ------------------------ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |  This is not actually supported. Notes are meant rather as inspiration. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |  Even though build output targets alien system, it's possible to execute | 
					
						
							|  |  |  |  test suite on Linux system by employing qemu-user. The trick is static | 
					
						
							|  |  |  |  linking. Pass -static to Configure, then edit generated Makefile and | 
					
						
							|  |  |  |  remove occurrences of -ldl and -pie flags. You would also need to pick | 
					
						
							|  |  |  |  API version that comes with usable static libraries, 42/2=21 used to | 
					
						
							|  |  |  |  work. Once built, you should be able to | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |     env EXE_SHELL=qemu-<arch> make test | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |  If you need to pass additional flag to qemu, quotes are your friend, e.g. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |     env EXE_SHELL="qemu-mips64el -cpu MIPS64R6-generic" make test |