Previously we used target triple as provided which matches the GCC
behavior, but it also means that all clients have to be consistent
in their spelling of target triples since e.g. x86_64-linux-gnu and
x86_64-unknown-linux-gnu will result in Clang driver looking at two
different paths when searching for runtime libraries.
Unfortunately, as it turned out many clients aren't consistent in
their spelling of target triples, e.g. many Linux distributions use
the shorter spelling but config.guess and rustc insist on using the
normalized variant which is causing issues. To avoid having to ship
multiple copies of runtimes for different triple spelling or rely on
symlinks which are not portable, we should use the normalized triple
when constructing paths for multiarch runtimes.
One possible alternative I've considered would be to simply return -lclang_rt.<component>.<suffix> instead of returning the full path when getLibraryPaths() is not empty. That should work because we add all paths in this list as -L in AddFilePathLibArgs and it's more consistent with e.g. -lgcc_s.