Support building on platforms without vendored assembly (OPENSSL_NO_ASM fallback, powerpc64le) - #450
Open
colemancda wants to merge 2 commits into
Open
Support building on platforms without vendored assembly (OPENSSL_NO_ASM fallback, powerpc64le)#450colemancda wants to merge 2 commits into
colemancda wants to merge 2 commits into
Conversation
The CMake build only defines platform sources for x86_64 and arm64 (plus their Windows variants); every other architecture hits a hard message(FATAL_ERROR) with no way to opt into a portable build. Replace the fatal error with the pure-C BoringSSL configuration by defining OPENSSL_NO_ASM for the CCryptoBoringSSL target. This is a supported BoringSSL build mode: the C implementations are always compiled and the assembly is only an optimization guarded by !defined(OPENSSL_NO_ASM). Platforms that do have vendored assembly are unaffected.
Upstream BoringSSL removed ppc64le support, so on powerpc64le neither OPENSSL_32_BIT nor OPENSSL_64_BIT gets defined and every header fails with: CCryptoBoringSSL_bn.h: error: "Must define either OPENSSL_32_BIT or OPENSSL_64_BIT" powerpc64le is a standard 64-bit two's-complement little-endian architecture, which is exactly what the portable C code supports per the comment above that #error. Add a detection branch defining OPENSSL_64_BIT, carried as scripts/patch-4-powerpc64le-target.patch and applied by vendor-boringssl.sh so it survives re-vendoring. OPENSSL_PPC64LE is deliberately not defined so no stale arch-specific code paths are enabled; the generic C implementation is used together with OPENSSL_NO_ASM.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Allow swift-crypto to build on Linux architectures that have no vendored BoringSSL assembly, and restore target detection for powerpc64le.
Checklist
Motivation:
The CMake build only defines platform sources for x86_64 and arm64 (plus their Windows variants); every other architecture — 32-bit ARM, i686, powerpc64le, RISC-V, MIPS — hits a hard
message(FATAL_ERROR "platform sources are not defined here ...")with no way to opt into a portable build, even though BoringSSL fully supports a pure-C configuration viaOPENSSL_NO_ASM(the assembly is only an optimization guarded by!defined(OPENSSL_NO_ASM)).Additionally, upstream BoringSSL removed powerpc64le from its target detection, so on ppc64le neither
OPENSSL_32_BITnorOPENSSL_64_BITgets defined and every header fails with:The comment above that
#errorexplicitly says the portable C code works on any standard 32/64-bit two's-complement little-endian architecture and invites carrying a local patch for such targets — powerpc64le qualifies.We hit both issues cross-compiling swift-crypto with CMake for embedded Linux targets (Buildroot) across armv5/armv6/armv7/i686/aarch64/x86_64/ppc64le; with these two changes the full matrix builds and the
Cryptomodule passes a runtime smoke test (SHA256.hash) on the non-asm architectures.Modifications:
Sources/CCryptoBoringSSL/CMakeLists.txt: replace theFATAL_ERRORfallback branch withtarget_compile_definitions(CCryptoBoringSSL PRIVATE OPENSSL_NO_ASM). Platforms that do have vendored assembly are unaffected.Sources/CCryptoBoringSSL/include/CCryptoBoringSSL_target.h: add a__powerpc64__+ little-endian branch definingOPENSSL_64_BIT. Since this file is vendored, the change is carried asscripts/patch-4-powerpc64le-target.patchand applied byscripts/vendor-boringssl.sh(alongside the existing patch-1/2) so it survives re-vendoring.OPENSSL_PPC64LEis deliberately not defined so no stale arch-specific code paths are enabled; the generic C implementation is used together withOPENSSL_NO_ASM.Result:
The CMake build succeeds on Linux architectures without vendored assembly (32-bit ARM, i686, powerpc64le, ...) using BoringSSL's supported pure-C configuration, instead of failing at configure time. x86_64 and arm64 continue to build their vendored assembly exactly as before. The powerpc64le detection fix also benefits SwiftPM builds on that architecture.