},
"solaris-sparcv8-gcc" => {
inherit_from => [ "solaris-sparcv7-gcc", asm("sparcv8_asm") ],
- cflags => sub { join(" ","-mv8",@_); },
+ cflags => sub { join(" ","-mcpu=v8",@_); },
},
"solaris-sparcv9-gcc" => {
# -m32 should be safe to add as long as driver recognizes
"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") ],
# patiently assisted with debugging of following two configs.
"linux-sparcv8" => {
inherit_from => [ "linux-generic32", asm("sparcv8_asm") ],
- cflags => "-mv8 -Wall -DB_ENDIAN -DBN_DIV2W",
+ cflags => "-mcpu=v8 -Wall -DB_ENDIAN -DBN_DIV2W",
},
"linux-sparcv9" => {
# it's a real mess with -mcpu=ultrasparc option under Linux,
},
#### 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") ],
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" => {
perlasm_scheme => "o32",
},
-#### *BSD [do see comment about ${BSDthreads} in Configure!]
+ "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" => {
- cc => "gcc",
+ # As for thread_cflag. Idea is to maintain "collective" set of
+ # flags, which would cover all BSD flavors. -pthread applies
+ # to them all, but is treated differently. OpenBSD expands is
+ # as -D_POSIX_THREAD -lc_r, which is sufficient. FreeBSD 4.x
+ # expands it as -lc_r, which has to be accompanied by explicit
+ # -D_THREAD_SAFE and sometimes -D_REENTRANT. FreeBSD 5.x
+ # expands it as -lc_r, which seems to be sufficient?
+ cc => "cc",
cflags => "-Wall",
debug_cflags => "-O0 -g",
release_cflags => "-O3",
- thread_cflag => "${BSDthreads}",
+ thread_cflag => "-pthread -D_THREAD_SAFE -D_REENTRANT",
bn_ops => "BN_LLONG RC2_CHAR RC4_INDEX DES_INT DES_UNROLL",
dso_scheme => "dlfcn",
shared_target => "bsd-gcc-shared",
"BSD-sparcv8" => {
inherit_from => [ "BSD-generic32", asm("sparcv8_asm") ],
- cflags => "-mv8 -Wall -DB_ENDIAN",
+ cflags => "-mcpu=v8 -Wall -DB_ENDIAN",
},
"BSD-sparc64" => {
# -DMD32_REG_T=int doesn't actually belong in sparc64 target, it
shared_extension => ".dll.a",
},
+#### UEFI
+ "UEFI" => {
+ cc => "cc",
+ cflags => "-DL_ENDIAN -O",
+ sys_id => "UEFI",
+ },
+
#### UWIN
"UWIN" => {
cc => "cc",
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",