[ddulaney]

I’m not OP, but at $WORK we sell a C++ library. We want to make it as easy as possible for clients to integrate it into their existing binaries. We need to be able to integrate with CMake, Meson, vcxproj, and hand-written Makefiles. We’re not the only vendor: if another vendor is using a specific cURL version, you better hope we work with it too, otherwise integration is almost impossible.

You could imagine us shipping our library as a DLL/.so and static-linking libcurl, but that comes with a bunch of its own problems.

[nly]

Exactly this. You don't want multiple versions of cURL loaded in to your process dynamically.

You need to be in control of the final link if you're shipping a .a to other teams

[progval]

That doesn't work if other teams want to apply their own cURL patches, or update as soon as upstream publishes new security fixes without waiting for you.

[nly]

That's the point. We don't do that. You link to the system libcurl dynamically and everyone is told to do the same.

If you want to use a private curl as an implementation detail then the only safe way to do it is to ship a .so, make sure all the symbols are private and that symbol interposition is switched off.

If you ship a .a then the final link can always make symbols public again.

[ddulaney]

There's also a sort-of informal "standard library" of C libraries that have super-stable ABI's that we can generally assume are either present on the system or easy to install. Zlib is another one that comes immediately to mind, but there are others as well.