Otherwise we embed a potentially absolute and potentially relative pathPrior to this change, for a few compiler-rt libraries such as ubsan and
the profile library, Clang would embed "-defaultlib:path/to/rt-arch.lib"
into the .drective section of every object compiled with
-finstr-profile-generate or -fsanitize=ubsan as appropriate.
These paths assume that the link step will run from the same working
directory as the compile step. There is also evidence that sometimes the
paths become absolute, such as when clang is run from a different drive
letter from the current working directory. This is fragile, and I'd like
to get away from having paths embedded in the object if possible. Long
to clang's resource directory into the object file.ago it was suggested that we use this for ASan, Object files withand apparently I felt
paths embedded in them are fragile and system specific, even when thethe same way back then:
path is relative. They cannot be put in an archive and distributed,https://reviews.llvm.org/D4428#56536
This is also consistent with how all other autolinking usage works for
examplePS4, Mac, and Windows: they all use basenames, not paths.
This will require users to add clang's library directory in its resourceTo keep things working for people using the standard GCC driver
directory to the linker libpathworkflow, but that is relatively easy compared tothe driver now adds the resource directory to the linker
computing the name of the appropriate compiler-rt library,library search path when it calls the linker. which isThis is enough to make
currently architecture dependentcheck-ubsan pass, and seems like a generally good thing.
This is also consistent with how autolinking seems to work for PS4Users that invoke the linker directly (most clang-cl users) will have to
add clang's resource library directory to their linker search path in
their build system. I'm not sure where I can document this. Ideally I'd
also do it in the MSBuild files, but I can't figure out where they go.
I'd like to start with this for now.