Linux armv7 support

[orobio]

On linux/armv7 some symbols are not properly prefixed. Building a project that includes both swift-nio-ssl and swift-crypto, results in the following conflicts:

ld.lld: error: duplicate symbol: CRYPTO_poly1305_init_neon
ld.lld: error: duplicate symbol: CRYPTO_poly1305_update_neon
ld.lld: error: duplicate symbol: CRYPTO_poly1305_finish_neon
ld.lld: error: duplicate symbol: openssl_poly1305_neon2_blocks
ld.lld: error: duplicate symbol: openssl_poly1305_neon2_addmulmod
ld.lld: error: duplicate symbol: vpaes_encrypt_key_to_bsaes
ld.lld: error: duplicate symbol: vpaes_decrypt_key_to_bsaes
ld.lld: error: duplicate symbol: sha512_block_data_order_neon
ld.lld: error: duplicate symbol: sha256_block_data_order_neon
ld.lld: error: duplicate symbol: bsaes_cbc_encrypt
ld.lld: error: duplicate symbol: bsaes_ctr32_encrypt_blocks
ld.lld: error: duplicate symbol: x25519_NEON
ld.lld: error: duplicate symbol: CRYPTO_has_broken_NEON
ld.lld: error: duplicate symbol: CRYPTO_needs_hwcap2_workaround

It looks like CCryptoBoringSSL_boringssl_prefix_symbols.h is generated by vendor-boringssl.sh by building BoringSSL for various architectures and gathering all symbols. There is no official linux/armv7 docker image yet, so at the moment we can't use the same method for adding these symbols, but would it be possible to create a temporary solution, for example by hardcoding these symbols? Or is there any proper solution that could work without requiring an official linux/armv7 docker?

[Lukasa]

I'd be open to an unofficial docker image, but I don't think hardcoding the symbols themselves is going to work. Another option might be to produce a cross-compilation SDK that supports an armv7 toolchain, which we could then integrate. @MaxDesiatov might be able to help with that.

[MaxDesiatov]

Swift SDKs can be generated from existing toolchains. Thus we need an armv7 toolchain first (for some Linux distribution, Docker images could work too) to run the generator on it.

[orobio]

We don't have a full toolchain for armv7, but we do have a cross-compiling toolchain (Swift 5.10). This was created with something based on the swift-armv7 repo. However, it is for our own Yocto based system. We can have a look at creating a container image with a cross-compiling toolchain for Debian. This should be usable with the vendor-boringssl.sh script. I guess it will not work well with the SDK generator, though.

[Lukasa]

Ideally we'd have either a suitable docker container or a toolchain, I don't much mind. Either way we can add that to the build system once we're there.

[orobio]

A container seems like the best option for now. It fits right into the current set-up and takes away some unknowns regarding SDK creation, especially for us being unfamiliar with Swift on MacOS. I submitted a pull request with a container based solution.

[xtremekforever]

Any updates on this? I wonder if the solution provided is not good enough to be used for generating symbols for armv7. Perhaps we can look into generating an SDK that is installable with swift sdk install for example?

[Lukasa]

I’m currently on vacation so don’t have cycles to review this. But it’s on my to-do list for when I’m back.

[xtremekforever]

Okay, that sounds good. I was going to look to see if we could generate an SDK for Debian armv7 anyways (interested for my own personal projects) so if that is something that would help for this I would be happy to look into it sooner rather than later. We have the ability to build for Debian armv7 and build a docker container, it's just the SDK generation that we don't know how to do yet...

[MaxDesiatov]

Feel free to submit a PR on the corresponding repo, which already supports a few other distributions that you could use as an example.