On 2026/07/29 15:25, Stuart Henderson wrote: > This project builds a patched curl with static-linked boringssl (with > C++ code); curl-impersonate upstream have been stumbling around trying > to figure out how to add the C++ standard library via 'cc -l<name>' > with all sorts of mess to try and figure out which library to use - > instead they should just use c++ to link. I haven't figured out how > to get that done directly in the standard build but did come up with > a pretty horrible workaround. If any cmake wizards want a challenge, > try to get it to link the executable directly with c++ as part of the > main build rather than the post-build monstrosity...you may end up > having to patch a patch.
I took your idea and made a few modifications to get it working properly. The changes have since been merged upstream, so building it should hopefully be considerably easier now (v2.2.3). It can also now be built with base-clang. I don't have much knowledge of ports, so I'm not sure whether this is actually the correct approach. However, I've attached a port archive containing a Makefile and patches that at least build and install successfully. If anyone has the time, could someone give it a try? > > Would be super cool if I could port over the python library as well. > > That is likely to be a problem. boringssl is statically linked into > libcurl-impersonate.so and trying to load this into the same address > space as python will likely result in a conflict with the libressl ones > used by python. I occasionally use curl_cffi through yt-dlp, and I haven't noticed any obvious problems with it. That said, I'm not very familiar with this area, so I'd appreciate any clarification on what I may be missing. I've also included the curl_cffi port in the archive. It's still rather rough.
curl-impersonate.curl_cffi.tgz
Description: application/compressed-tar
