phosek added a comment.
Sorry about the late response, I was mostly out last week. This recently came
up again so I'd like to look into it but I'll have to rethink the change and
come up with a better approach.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
Hahnfeld added a comment.
Herald added a project: clang.
Going through my old revisions, is this still something that we want?
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D53250/new/
https://reviews.llvm.org/D53250
phosek added a comment.
In https://reviews.llvm.org/D53250#1264708, @Hahnfeld wrote:
> If I read that patch correctly, this will render `-fuse-ld` with non-absolute
> paths useless if a toolchain has `DefaultLinker != "ld"`. I don't think
> that's what we want to do if the user explicitly sets
Hahnfeld added a comment.
If I read that patch correctly, this will render `-fuse-ld` with non-absolute
paths useless if a toolchain has `DefaultLinker != "ld"`. I don't think that's
what we want to do if the user explicitly sets a different linker.
In https://reviews.llvm.org/D53250#1264626,
phosek added a comment.
This should avoid workarounds such as https://reviews.llvm.org/D49899 or
https://reviews.llvm.org/D53249.
Repository:
rC Clang
https://reviews.llvm.org/D53250
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
phosek created this revision.
phosek added reviewers: rsmith, Hahnfeld.
Herald added a subscriber: cfe-commits.
When the toolchain overrides default linker, use it rather than the
default Clang one which is unlikely to be useable for that toolchain
anyway. This avoids the need to explicitly
