aboutsummaryrefslogtreecommitdiff
path: root/CMakeLists.txt
diff options
context:
space:
mode:
authorDavid Benjamin <davidben@google.com>2023-01-25 10:03:53 -0500
committerBoringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com>2023-01-26 22:55:32 +0000
commit1967621cc9498a4d775a8a9eaabbcb7a52be8316 (patch)
tree5cebf96038d7ee686c14aeffa3c854428e30543b /CMakeLists.txt
parenta43c76dbe30d619188dc685b7d432a92e7c2b66b (diff)
downloadboringssl-1967621cc9498a4d775a8a9eaabbcb7a52be8316.zip
boringssl-1967621cc9498a4d775a8a9eaabbcb7a52be8316.tar.gz
boringssl-1967621cc9498a4d775a8a9eaabbcb7a52be8316.tar.bz2
Reduce architecture detection in CMake.
This follows up on https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make the CMake build rely on the C preprocessor, rather than CMake. While not as disasterous as pre-@platforms Bazel, CMake's build-level platform selection is not ideal: - CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names for the same architecture, and sometimes, e.g., building for 32-bit Windows will still report "AMD64". - On Apple platforms, there is a separate and technically multi-valued CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but don't support the multi-value case. Instead, broadly detect whether we expect gas or nasm, and then pull in every matching file, relying on the C preprocessor to exclude files as needed. This also fixes a quirk in generate_build_files.py, where it needed to use the filename to detect the architecture of a perlasm script in CMake. This CL only applies to the standalone CMake build. The generated file lists do not change. I'm not sure yet whether this strategy will be appropriate for all those builds, so this starts with just the CMake one. This hits a pair of nuisances with the Apple linker. First, Apple has two ways to invoke the linker. The new way is libtool, the old way is ranlib. Warnings are different between the two. In both libtool and ranlib, for x86_64 but not aarch64, we get a warning about files with no symbols. This warning fires for us, but this change makes it much, much noisier. Oddly, this warning does not trigger when building for aarch64, just x86_64. I'm not sure whether this is because aarch64 hits new behavior or it happens that aarch64 object files always contain some dummy symbol. libtool has a -no_warning_for_no_symbols flag to silence this warning. Unfortunately, CMake uses ranlib and there is no way, from what I can tell, to pass this flag to ranlib. See https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698 Since this seems to be a broader CMake limitation, and we were already living with some of these warnings, I've left this alone. But this CL does make macOS x86_64 CMake builds very noisy. I haven't used it here, but LLVM has a pile of CMake goo that switches CMake to using libtool and passes in that flag. Trialing it out reveals *different* issue, which I have worked around: When invoked as libtool, but not as ranlib, the Apple linker also warns when two object files have the same name. This appears to be a holdover from static libraries using ar, even though ld does not actually invoke ar. There appears to be no way to suppress this warning. Though we don't use libtool, we can probably assume most non-CMake builds will be using the modern spelling. So I've suffixed each perlasm file with the OS. This means, in generate_build_files.py, we no longer need a separate directory for each platform. For now, I've kept that alone, because some update scripts rely on that spelling to delete old files. Update-Note: If the CMake build fails to build somewhere for an assembly-related reasons, it's probably from this CL. Bug: 542 Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
Diffstat (limited to 'CMakeLists.txt')
-rw-r--r--CMakeLists.txt83
1 files changed, 30 insertions, 53 deletions
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 7e5a648..4c39d12 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -16,6 +16,7 @@ if(WIN32)
endif()
include(sources.cmake)
+include(cmake/perlasm.cmake)
enable_language(C)
enable_language(CXX)
@@ -404,66 +405,42 @@ function(go_executable dest package)
endif()
endfunction()
-# CMake's iOS support uses Apple's multiple-architecture toolchain. It takes an
-# architecture list from CMAKE_OSX_ARCHITECTURES, leaves CMAKE_SYSTEM_PROCESSOR
-# alone, and expects all architecture-specific logic to be conditioned within
-# the source files rather than the build. This does not work for our assembly
-# files, so we fix CMAKE_SYSTEM_PROCESSOR and only support single-architecture
-# builds.
-if(NOT OPENSSL_NO_ASM AND CMAKE_OSX_ARCHITECTURES)
- list(LENGTH CMAKE_OSX_ARCHITECTURES NUM_ARCHES)
- if(NOT NUM_ARCHES EQUAL 1)
- message(FATAL_ERROR "Universal binaries not supported.")
+if(OPENSSL_NO_ASM)
+ add_definitions(-DOPENSSL_NO_ASM)
+endif()
+
+if(FIPS_DELOCATE OR NOT OPENSSL_NO_ASM)
+ # On x86 and x86_64 Windows, we use the NASM output.
+ if(WIN32 AND CMAKE_SYSTEM_PROCESSOR MATCHES "AMD64|x86_64|amd64|x86|i[3-6]86")
+ enable_language(ASM_NASM)
+ set(OPENSSL_NASM TRUE)
+ set(CMAKE_ASM_NASM_FLAGS "${CMAKE_ASM_NASM_FLAGS} -gcv8")
+ else()
+ enable_language(ASM)
+ set(OPENSSL_ASM TRUE)
+ # CMake does not add -isysroot and -arch flags to assembly.
+ if(APPLE)
+ if(CMAKE_OSX_SYSROOT)
+ set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -isysroot \"${CMAKE_OSX_SYSROOT}\"")
+ endif()
+ foreach(arch ${CMAKE_OSX_ARCHITECTURES})
+ set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -arch ${arch}")
+ endforeach()
+ endif()
+ if(NOT WIN32)
+ set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -Wa,--noexecstack")
+ endif()
+ # Clang's integerated assembler does not support debug symbols.
+ if(NOT CMAKE_ASM_COMPILER_ID MATCHES "Clang")
+ set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -Wa,-g")
+ endif()
endif()
- list(GET CMAKE_OSX_ARCHITECTURES 0 CMAKE_SYSTEM_PROCESSOR)
endif()
if(OPENSSL_NO_SSE2_FOR_TESTING)
add_definitions(-DOPENSSL_NO_SSE2_FOR_TESTING)
endif()
-if(OPENSSL_NO_ASM)
- add_definitions(-DOPENSSL_NO_ASM)
- set(ARCH "generic")
-elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
- set(ARCH "x86_64")
-elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "amd64")
- set(ARCH "x86_64")
-elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "AMD64")
- # cmake reports AMD64 on Windows, but we might be building for 32-bit.
- if(CMAKE_SIZEOF_VOID_P EQUAL 8)
- set(ARCH "x86_64")
- else()
- set(ARCH "x86")
- endif()
-elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86")
- set(ARCH "x86")
-elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "i386")
- set(ARCH "x86")
-elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "i686")
- set(ARCH "x86")
-elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "aarch64")
- set(ARCH "aarch64")
-elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "ARM64")
- set(ARCH "aarch64")
-elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "arm64")
- set(ARCH "aarch64")
-# Apple A12 Bionic chipset which is added in iPhone XS/XS Max/XR uses arm64e architecture.
-elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "arm64e")
- set(ARCH "aarch64")
-elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "^arm*")
- set(ARCH "arm")
-elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "mips")
- # Just to avoid the “unknown processor” error.
- set(ARCH "generic")
-elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "ppc64le")
- set(ARCH "ppc64le")
-elseif (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "riscv64")
- set(ARCH "riscv64")
-else()
- message(FATAL_ERROR "Unknown processor:" ${CMAKE_SYSTEM_PROCESSOR})
-endif()
-
if(USE_CUSTOM_LIBCXX)
if(NOT CLANG)
message(FATAL_ERROR "USE_CUSTOM_LIBCXX only supported with Clang")