Page MenuHomePhabricator

Use library basenames when autolinking on Windows
Needs ReviewPublic

Authored by rnk on Jul 31 2019, 2:58 PM.

Details

Summary

Otherwise we embed a potentially absolute and potentially relative path
to clang's resource directory into the object file. Object files with
paths embedded in them are fragile and system specific, even when the
path is relative. They cannot be put in an archive and distributed, for
example.

This will require users to add clang's library directory in its resource
directory to the linker libpath, but that is relatively easy compared to
computing the name of the appropriate compiler-rt library, which is
currently architecture dependent.

This is also consistent with how autolinking seems to work for PS4.

Event Timeline

rnk created this revision.Jul 31 2019, 2:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 31 2019, 2:58 PM
Herald added a subscriber: srhines. · View Herald Transcript
pcc added a comment.Jul 31 2019, 3:25 PM

The idea behind embedding the path was that these objects are usually not distributed, so things usually just work.

Is there some other way that we could arrange for the linker to search the sanitizer library directory automatically? Maybe we could add the path to one of the files in llvm/tools/msbuild? I guess that wouldn't solve the problem for command-line users but maybe that's enough.

rnk added a comment.Aug 1 2019, 11:11 AM

I'll look into that. I also noticed that check-ubsan fails. I think we should also change clang's driver to add this libpath when it invokes the linker, so that this works transparently when using the GCC-style driver.

I kind of like the current behavior since it's consistent with how resource dirs are passed to cc1, and how FILE expands if you give a relative work to clang, and how debug info paths look if you pass relative paths to clang.