BoringSSL conflicting symbols for Armv7

[colemancda]

I encountered an issue with integrating CryptoKit (nested dependency) and SwiftNIO in a single project cross compiled for Armv7, since its statically linked and both seem to vendor BoringSSL.

swift-nio-ssl/CNIOBoringSSL swift-crypto/CCryptoBoringSSL

Swift-armv7-CryptoKit.log

[Lukasa]

We'll need to add support for armv7 builds to our cross-compile checks. Are you able to produce a x-compile toolchain for Linux armv7 we can use?

[colemancda]

I was able to generate a toolchain, https://github.com/colemancda/swift-armv7/actions/runs/3304509240 Just clone https://github.com/colemancda/swift-armv7 and run

./generate-xcode-toolchain.sh
export SWIFT_PACKAGE_SRCDIR=/home/user/Developer/MySwiftPackage
export SWIFT_NATIVE_PATH=/tmp/cross-toolchain/debian-bullseye.sdk
./build-swift-package.sh

[Lukasa]

So I think that doesn't quite have the shape we're looking for. Ideally it should produce a toolchain that we can use with --destination as shown here: https://github.com/apple/swift-nio-ssl/blob/4fb7ead803e38949eb1d6fabb849206a72c580f3/scripts/vendor-boringssl.sh#L114.

[colemancda]

After running ./generate-xcode-toolchain.sh, you should have the destination file in ./build/armv7-unknown-linux-gnueabihf-toolchain.json

[Lukasa]

So as a piece of feedback, ideally the .json paths here wouldn't be absolute, and wouldn't be temporary (they point into /tmp). Instead, they'd be ready to be installed in the various directories under /Library/Developer.

[colemancda]

I agree, but I adopted this from https://github.com/apple/swift-package-manager/blob/main/Utilities/build_ubuntu_cross_compilation_toolchain and wanted to make as few changes as possible

[colemancda]

Also I wasn't aware that the destination.json format would work without absolute paths.