Then you want to add a library that compiles fine on Fedora, but fails on ArchLinux, because they've moved some header file from `/usr/include` to `/usr/include/subdir`.
Then you want to add another library, but you want to statically link it, only to find out that the package manager installs a version of the library that allows only dynamic linkage.
Then you want to add Windows support, and the whole thing detonates because Visual Studio uses completely different compilation switches than what you'd expect from a compiler in a unix world.
Next there are 1000 other problems, including people who insist on using raw Makefiles because they think they know better.
By the way, the fact that C doesn't use rich signatures is a problem, not a feature. C ABI can also be changed by using different compilation options, but the user won't even know it until the app explodes (crashes). At least C++ will emit a linker error in such case (sometimes, other times it will explode as well).
This is why pkg-config exists.
>Then you want to add another library, but you want to statically link it, only to find out that the package manager installs a version of the library that allows only dynamic linkage.
This sounds like a problem in such "package manager" or problem in the upstream build system.
>Then you want to add Windows support, and the whole thing detonates because Visual Studio uses completely different compilation switches than what you'd expect from a compiler in a unix world
This is a valid point. Visual studio already has its own solution however. I personally avoid visual studio anyways, because it sucks for C.
>Next there are 1000 other problems, including people who insist on using raw Makefiles because they think they know better.
These aren't really problems unless you rely only on the upstream build system. PKGBUILDs, nix recipes they can do their own thing.
One could, but no one has. That's the whole discussion, there are multiple partial implementations with limited adoption.