cmake: add option to build and link BoringSSL
This commit adds an easy way to fetch, build, and statically link the BoringSSL library when LLAMA_BUILD_BORINGSSL is enabled.
The version can be set via the LLAMA_BORINGSSL_VERSION cache variable.
Few observations:
- On Mac builds, there are quite a lot of compile warnings when building BoringSSL. Need to disable those
- The SSL stuff is now embedded in all tools and examples increasing their binary size. We should build a shared
libllama-commonlibrary - Do we need to create some CI workflows to make sure BSSL builds are succssful?
- The SSL stuff is now embedded in all tools and examples increasing their binary size. We should build a shared
libllama-commonlibrary
As a quick fix, I can support BUILD_SHARED_LIBS=ON by just renaming our libssl to libllama-ssl to avoid conflicts:
build/bin/llama-server:
@rpath/libmtmd.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libllama-ssl.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libllama-crypto.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 4040.1.255)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 61901.0.87)
@rpath/libllama.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libggml.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libggml-cpu.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libggml-blas.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libggml-metal.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libggml-base.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 2000.63.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
- Do we need to create some CI workflows to make sure BSSL builds are succssful?
Yes, my plan is to progressively remove curl in the CI, step by step, until it’s completely gone.
Also I don’t expect most users to actually use the BoringSSL build, for almost everyone LLAMA_OPENSSL should be enough.
Quick heads up, BoringSSL does not support the s390x platform due to endianness issues. So if possible for CI tests, exclude s390x from the BoringSSL tests.
I'll refactor this PR after the merge of #17177
supersed by #17205