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
https://reviews.llvm.org/D53250
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
http:/
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 specif
