> PS: the original motiviation for the STB single-file libs was actually that Windows doesn't have a default place where dependencies are installed

I've had so many issues with shared libs on linux in the past, I gave up on it and started to include all the necessary source of any third party library in my projects. Makes building and distributing things much easier.

In other language build environments it's called vendorising and Ruby, Go, and Rust offer tooling to do this for the various benefits (hermetic builds, dealing with down infra, not molesting third party source control, not leaking information about your dependencies to third parties).

...shared dependencies are more often a problem and not a solution, even when a standard package manager exists (see the deep dependency trees in many Javascript projects where nobody really knows what's actually going on and what code ends up running).

Do you have examples of this or is it just a guess?

Anything in its own compilation unit would be isolated. Anything written using C++03 should compile without too much trouble in a more modern compiler.

Also threading is part of the C++ standard library.

I don't know what you mean by sharing dependencies on telemetry and logging. That sounds like adding questionable complexity to libraries that are simple and modular.

> Anything in its own compilation unit would be isolated

In isolation yes. But if it interacts you get events like the fact that gcc changed std::string between versions (from refcounted to one with small buffer optimisation for C++11 compliance) also introduction of move semantics and rvalue references can change interpretation of the same class declaration between compilers in different modes.

I have never heard of people upgrading their compiler and/or standard libraries, but expecting to not have to recompile their compilation units.

You seem to be talking about major changes to the fundamental set up of a project while not taking a comparably trivial amount of time recompiling compilation units.

How often are you changing major compiler versions and breaking standard library versions that you would have this expectation?

> I have never heard of people upgrading their compiler and/or standard libraries, but expecting to not have to recompile their compilation units.

You've never linked to a binary? I have no idea what debian's Qt was build with or libssl or SDL etc were built with but we can link to them all the same.

> How often are you changing major compiler versions and breaking standard library versions that you would have this expectation?

You don't configure Jenkins to build against multiple compilers/versions of compiler? Isn't that super normal?

You are conflating the C ABI with the C++ ABI. The C ABI is stable, so linking to SDL works fine. The C++ ABI is actually relatively stable as far as I can tell, but ABI breaking changes are announced when they are released by compiler vendors.

I am intentionally conflating the C ABI with the C++ ABI because the C++ ABI is only relatively stable so if you want to write software that doesn't require you to rebuild everything each time you update a compiler then you push your code to use more C ABIs rather than more advanced C++isms. This is exactly what SDL has done as the headers are C compatible but it has plenty of C++ in the direct3d parts.

This was originally about grouping single file header libraries into compilation units that wouldn't need to be changed often. I'm not sure what your point here is, since most would have C functions for their interface or use templates. Even if you were using a C++ ABI it would be trivial to recompile. Qt is the furthest thing from a single file library.