ggml-org
cmake : move OpenSSL linking to vendor/cpp-httplib
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 👀
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~~
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
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
Why was visionOS not an issue before? The 0.27.0 version was also used just before the split commit 🤔
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
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 ?
Instead of splitting maybe we can create a generic
http.hlimited to our requirements and simply include the complete, unmodifiedhttplib.hfile in a newhttp.cppfile that do the necessary glue code ?
no because server.cpp compilation time will still be long.
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.
Currently it’s very slow because every time we include
common.h, we have to handlehttplib.has 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.
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.
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.
@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 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).
My point was that having an
http.hwith only the interface (class, prototypes, whatever) and anhttp.cppthat fully includes thehttplib.hplus the glue code will be almost as fast as the splitting solution. Because you will have only one compilation unit.
Ofc as I explained earlier that can be the long-term plan. But what's not clear how the interface should look like.
But again, since we don't know when it will come and I don't want to waste too much time while working on server.cpp, the current solution "just work".
I appreciate whatever solution that reduces the compilation time of server.cpp though.
Simply use httplib 0.19.0 (if you even must), and never upgrade again. The dev is too incompetent to maintain even Windows 7 compatibility (and has declared it "unsupported" instead), why would you even trust his code?
He needs Windows 10 to parse HTTP ffs
In https://github.com/ggml-org/llama.cpp/pull/17216 , I introduce a high-level HTTP interface that will be framework-agnostic. We can later move the implementation of HTTP server completely to libcommon