cmake : add option to build and link LibreSSL

[angt]

Tested with cmake 4.1.2 and 3.23.3

[angt]

@ggerganov this PR was for your concerns about BoringSSL. We now offer all scenarios supported by cpp-httplib.

[ggerganov]

@angt Thanks. I was mainly trying to understand when would we want to use an alternative to OpenSSL. Ideally, I would think that we just always link to OpenSSL. But maybe there is something that prevents us to do that and that's why we need these alternatives?

When I looked sometime ago into OpenSSL, it seemed a bit difficult to provide the binaries for all platforms. With BoringSSL, and now with LibreSSL too, we fetch the source code and build it. Can we do the same with OpenSSL?

[angt]

Yes! there is no official integration of OpenSSL in cmake, so we need to make our own and maintain it, or bundle a bunch of Shell/PowerShell scripts with all the build dependencies for all targets. This is not trivial at all (I tried 😅 you also need to duplicate all crossbuilding code to make sure everything works aligned and sync the new one).

BoringSSL is a far better solution IMO. It is used by Google Chrome/Android/etc. and backed by Google, offering official cmake integration. So just a few lines of cmake code enabled me to build llama.cpp with SSL for Linux, Windows, macOS, and FreeBSD without any trouble, any additional scripts, crossbuilding or not. The same for LibreSSL.

But LLAMA_OPENSSL is perfect for building locally, it works for OpenSSL, BoringSSL, and LibreSSL too. While LLAMA_BUILD_*SSL is made for packaging, which I already use for installama.sh.

[JamePeng]

@angt @ggerganov Is it possible to choose one of the libraries with high compatibility and keep it in the vendor as a component to keep the submomdule, especially on the Windows platform. Recently, it was discovered that the introduction of BoringSSL resulted in multiple versions downloading BoringSSL each time they were compiled at the same time (up to 300+MB), which consumes a lot of traffic.

[angt]

@angt @ggerganov Is it possible to choose one of the libraries with high compatibility and keep it in the vendor as a component to keep the submomdule, especially on the Windows platform. Recently, it was discovered that the introduction of BoringSSL resulted in multiple versions downloading BoringSSL each time they were compiled at the same time (up to 300+MB), which consumes a lot of traffic.

In which situation? BoringSSL and LibreSSL are essentially there to support distributing llama.cpp binaries in the near future.

The reasoning behind the current setup is that if you build BoringSSL or LibreSSL, you’ll need to download their sources anyway. Vendoring them would just make llama.cpp larger and slower for everyone, even though almost nobody should need to build them locally. The intended path for local builds is to rely on LLAMA_OPENSSL instead.

[JamePeng]

OK