I’m not sure what problem you’re trying to solve here. These libraries tend to be tightly coupled to the platform, or possibly toolchain, not something that I’d want users to modify (unless they knew what they were doing enough to pass -nostdlib and provide the full set themselves).
The problem is that Compiler-RT doesn't include the low-level
implementation libraries, such as unwinders and C++ ABI, but libgcc
does via libgcc_s/eh. So, when using compiler-rt via --rtlib, that
functionality is missing, whereas it wasn't if you use libgcc. This is
inconsistent, as it claims to change the run time library, but doesn't
change all of it, and users are left scratching their heads.
The way I "fixed" this in the past is to automatically add libgcc_*
with compiler-rt if on GNU systems. This is horrible and must be
killed with fire.
On FreeBSD, we don’t explicitly link the C++ ABI library, because libc++.so is a linker script. We link compiler-rt, but our build of compiler-rt is called libgcc, for compatibility. On OS X, the libraries that implement these things are also quite specific. On Windows, they’ll depend a lot on whether you’re using a Cygwin, MinGW, or VS toolchain.
Exactly. This is why I'm changing ToolChain to have their own
defaults, which the user can override, without needing to go all the
way down to --nostdlib. It's not a full solution to all problems, but
it's a convenient way to test (and later make the default) to some of
the libraries that LLVM bundles together.
I imagine that for FreeBSD, even though you use libc++ and
compiler-rt, it will still be called libgcc*, so nothing changes for
you. The default is still GCC. But I don't think it's a good path for
everyone to keep symlinks, linker scripts and wrongly-named binaries
for all OSs.
The usage I expect to happen is:
1. Default behaviour, no rtlib no rtimpl. This would check the
environment, use ToolChain::GetDefaultRuntimeLibType and
ToolChain::GetDefaultRuntimeImplLibType to know what to include, and
do it. Most of the time, this will mean libgcc*.
2. Changing one, not the other. This would change the default
behaviour of the platform for the rtlib/rtimpl, but still use the
default runtime library/implementation. You use this when you want to
test/use only compiler-rt, or libunwind, but not the rest that is the
default in your platform.
4. Change both. I need this to test RT + unw + c++abi to validate it
on buildbots. Alternative Clang-based front-ends could pick and choose
their defaults just by overriding
Advanced users, that want to use -nostdlib, can still have the full
freedom to pick and choose whatever they want. But for the end user,
being able to change the runtime library and its implementation with
one or two high-level parameters is a nice thing.