cmake : move OpenSSL linking to vendor/cpp-httplib

[angt]

This commit fixes the compilation with OpenSSL, but it doesn’t fix SSL....
The use of version 0.20.1 of cpp-httplib (instead of 0.27.0) might be the only culprit, no idea how to update the code tho

cc @ngxson 👀

[ngxson]

The use of version 0.20.1 of cpp-httplib (instead of 0.27.0) might be the only culprit, no idea how to update the code tho

If you spot a problem, you should raise an issue to the original repo: https://github.com/yhirose/cpp-httplib

It is not recommended to downgrade the code in any cases, as it may lead to security & stability issues such as this one

[ngxson]

ok sorry I totally missed that the version was hard-coded in scripts/sync_vendor.py

if someone upgrade vendor version, please also change the version in the file. otherwise the old version will be pulled each time a contributor run the script

[ngxson]

@angt can you check if SSL is working now? httplib is bump to 0.27.0

[angt]

It works now :)

[ngxson]

hmm, seems like the newer httplib version breaks the Vision OS build (again): https://github.com/ggml-org/llama.cpp/actions/runs/19278477351/job/55123989425?pr=17177

[ngxson]

@ggerganov tagging you for visibility, I had to add this to be able to exclude httplib from visionOS build, as it's not compatible

[angt]

Why was visionOS not an issue before?
The 0.27.0 version was also used just before the split commit 🤔

[ngxson]

That's because we only compile part of the code with header-only. When the lib is moved to a dedicated targer, it must compile all functions. Unused functions are discarded at linking

[angt]

Instead of splitting maybe we can create a generic http.h limited to our requirements and simply include the complete, unmodified httplib.h file in a new http.cpp file that do the necessary glue code ?

[ngxson]

Instead of splitting maybe we can create a generic http.h limited to our requirements and simply include the complete, unmodified httplib.h file in a new http.cpp file that do the necessary glue code ?

no because server.cpp compilation time will still be long.

[angt]

Hmm you sure?
In both cases you only have one compilation unit to handle.

Currently it’s very slow because every time we include common.h, we have to handle httplib.h as well.

[ngxson]

Currently it’s very slow because every time we include common.h, we have to handle httplib.h as well.

compiling server.cpp is slow because it include httplib.h directly with implementations inside, not because it's included via common.h

and no, include common.h does not also include httplib.h (if yes, why?). if you look into common.h, there is no other include that links to either json.hpp or httplib.h. only either including download.h or http.h does that.

and lastly, splitting cpp/h is actually an option provided by httplib. I don't see why we can't use it. Indeed, we should, as we don't want to re-compile the same code in multiple places. a good example is json.hpp where it's currently used by too many components, and simply optimizing it can increase the compilation speed quite a lot.

[ngxson]

Re. your point about only one single compilation unit. Currently without splitting cpp/h, the lib will be compiled in 2 places, both libcommon (only the httplib::Client is used) and llama-server (httplib::Server), so it's being compiled twice now.

Ofc we can also just move the server part to http.h (I remember we discussed about this back then). But we are still unsure how the implementation should look like. I think we can consider moving back to header-only once we figure this out.

[ggerganov]

That's because we only compile part of the code with header-only. When the lib is moved to a dedicated targer, it must compile all functions. Unused functions are discarded at linking

https://github.com/ggml-org/llama.cpp/actions/runs/19278477351/job/55123989425#step:5:217

This is a compile error, not a linker error. In both cases the entire code of httplib is compiled.

Most likely httplib does not include certain headers that are needed for VisionOS. Before we likely included those header indirectly, before including the httplib. Ideally httplib should start including these headers and it would not be necessary to turn it off on our end.

[angt]

No, I meant that it was included in common.h before your split, so every compilation unit that included it had to recompile it before.
I believe this was the primary reason for the slow compilation. So splitting or putting the entire file in its own compilation unit will have the same effect.

[ngxson]

@angt the total compilation time stays unchanged. But each time I modify the code in server.cpp then recompile it, without having httplib in its own unit, it takes 24 seconds to finish. After the split it only takes 16s. And that's what matters for someone who spend quite a lot of time working on server.cpp

Without splitting, what's your solution then?

[angt]

@angt the total compilation time stays unchanged. But each time I modify the code in server.cpp then recompile it, without having httplib in its own unit, it takes 24 seconds to finish. After the split it only takes 16s. And that's what matters for someone who spend quite a lot of time working on server.cpp

Without splitting, what's your solution then?

I have no issue with the splitting solution :) just pointing out another way without touching the header-only provided by cpp-httplib.

My point was that having an http.h with only the interface (class, prototypes, whatever) and an http.cpp that fully includes the httplib.h plus the glue code will be almost as fast as the splitting solution. Because you will have only one compilation unit.

Another benefit is that with our own interface, cpp-httplib becomes a provider. So we could later rely on the Security/Network framework of macOS and have native HTTP/HTTPS support directly (or the one provided by Windows).