The standard was initially meant to standardize existing practice. There is no good existing practice. Very large institutions depending heavily on C++ systematically fail to manage the build properly despite large amounts of third party licenses and dedicated build teams.
With AI, how you build and integrate together fragmented code bases is even more important, but someone has yet to design a real industry-wide solution.
I'm doing a migration of a large codebase from local builds to remote execution and I constantly have bugs with mystery shared library dependencies implicitly pulled from the environment.
This is extremely tricky because if you run an executable without its shared library, you get "file not found" with no explanation. Even AI doesn't understand this error.
You can also very easily harden this if you somehow don't want to capture libraries from outside certain paths.
You can even build the compiler in such a way that every binary it produces has a built-in RPATH if you want to force certain locations.
I can only infer that your lack of familiarity was what made it take so long.
Rebuilding GCC with specs does take forever, and building GCC is in general quite painful, but you could also use patchelf to modify the binary after the fact (which is what a lot of build systems do).
Pretty much.
Trying to convert an existing build that doesn't explicitly declare object dependencies is painful. Rust does it properly by default.
For example, I'm discovering our clang toolchain has a transitive dependency on a gcc toolchain.
In general though, a clang install will still depend on libstdc++, libgcc, GCC crtbegin.o and binutils (at least on Linux), which is typically why it will refer to a specific GCC install even after being built.
There are of course ways to use clang without any GCC runtime, but that's more involved and non-standard (unless you're on Mac).
And there is also the libc dependency (and all sysroot aspects in general) and while that is usually considered completely separate from GCC, the filesystem location and how it is found is often tied to how GCC is configured.
(And "absolute" or other adjectives don't qualify "correctness"... it simply is or isn't.)