cmake: add option to build and link BoringSSL

[angt]

No description provided.

[ggerganov]

This does not build on Mac:

cmake -B build-boring -DLLAMA_BUILD_BORINGSSL=ON
cmake --build build-boring -j

[100%] Building CXX object tools/server/CMakeFiles/llama-server.dir/server.cpp.o
In file included from /Users/ggerganov/development/github/llama.cpp/tools/server/server.cpp:2:
In file included from /Users/ggerganov/development/github/llama.cpp/tools/server/utils.hpp:12:
/Users/ggerganov/development/github/llama.cpp/common/../vendor/cpp-httplib/httplib.h:340:10: fatal error: 'openssl/err.h' file not found
  340 | #include <openssl/err.h>
      |          ^~~~~~~~~~~~~~~
1 error generated.
make[2]: *** [tools/server/CMakeFiles/llama-server.dir/server.cpp.o] Error 1
make[1]: *** [tools/server/CMakeFiles/llama-server.dir/all] Error 2

[angt]

It worked for me because I tested OpenSSL just before I guess..

[angt]

Fixed, I thought I could put the library in PRIVATE but the header still exposes all the SSL stuff.

[angt]

I've added the ci for windows and macos

@ggerganov do you want to update release in the same PR?

[CISC]

On an (un)related note I see we have these:

llama.cpp/.github/workflows/build.yml

Line 92 in 2ba8b25

ctest -L 'main|curl' --verbose --timeout 900

llama.cpp/.github/workflows/build.yml

Line 232 in 2ba8b25

ctest -L 'main|curl' --verbose --timeout 900

But I can't see that we are using the curl test label anywhere?

[ggerganov]

Is there a way to use OpenSSL for the CI?

A bit worried about making BoringSSL the default since from their site, they don't recommend that:

[angt]

I've found this:

llama.cpp/examples/eval-callback/CMakeLists.txt

Lines 7 to 15 in 845f200

	set(TEST_TARGET test-eval-callback)
	if(NOT ${CMAKE_SYSTEM_PROCESSOR} MATCHES "s390x")
	add_test(NAME ${TEST_TARGET}
	COMMAND llama-eval-callback --hf-repo ggml-org/models --hf-file tinyllamas/stories260K.gguf --model stories260K.gguf --prompt hello --seed 42 -ngl 0)
	else()
	add_test(NAME ${TEST_TARGET}
	COMMAND llama-eval-callback --hf-repo ggml-org/models --hf-file tinyllamas/stories260K-be.gguf --model stories260K-be.gguf --prompt hello --seed 42 -ngl 0)
	endif()
	set_property(TEST ${TEST_TARGET} PROPERTY LABELS eval-callback curl)

[angt]

I've used OpenSSL for linux: #17235

For windows and macos, I really recommend BoringSSL. I know the message from Google is kind of scary, but the OpenSSL API has always been respected (they can't patch the entire world to link against BoringSSL anyway) and it is the best choice in my opinion, for safety and portability.

That's said, I plan to add other libraries in the future, mostly to reduce compilation time by using the native OS stack when available.

[ggerganov]

I see, I missed #17235

I think this change for the CI is OK.

For my understanding, what is the reason for preferring BoringSSL over OpenSSL for Windows and Mac?

[angt]

I use OpenSSL on Linux only because it's super easy to have the libssl-dev and link against it, making the build faster when you don’t have to publish the binary. For installama.sh, I always statically link to BoringSSL.

[ggerganov]

If the only concern is build time, I think that for the releases we'll want to use OpenSSL as it is not that important to reduce the build time there.

[angt]

@ggerganov, just thinking, why not keep tinyllamas/stories260K.gguf in the models directory like other tests? Is this legacy or a voluntary way to keep a download test?

[ggerganov]

The other ggufs in models are vocab-only models for tokenizer tests.

The stories260K.gguf is small enough to keep in models, but it would be an exception since the tests also download other models that we don't want to store in the repo. So I don't think there is a good reason to change it.