[clang] [Driver] Restore compiler-rt arch suffix for PS and Windows (PR #89775)
Martin Storsjö via cfe-commits
cfe-commits at lists.llvm.org
Tue Apr 23 09:27:50 PDT 2024
mstorsjo wrote:
> Commit [b876596](https://github.com/llvm/llvm-project/commit/b876596a76cdc183439b36455d26883b67f8ee51) corrected default compiler-rt library names for many targets
Are you sure it's this change? There are reports of similar changes showing up in https://github.com/llvm/llvm-project/pull/87866#issuecomment-2072684950, caused by ccdebbae4d77d3efc236af92c22941de5d437e01 (#87866)
> It's been like that for maybe 2-3 years now and no one has complained about it
The old status quo has been that you can build the runtimes with either layout, and clang will use whichever it finds, when invoking the linker.
The recent changes, #81037 and #87866, were (as far as I know) only intended to change what is printed as error messages, when neither is found, to help users correct their setup for the new style layout. But those changes also seem to have unexpected effects in changing e.g. what gets emitted as embedded directive, when the compiler doesn't see either of them at compile time (with e.g. distributed build systems), while they might be available at link time.
> but last time it was discussed I think @MaskRay was against a new variable, but since we might need to have some different behaviour it might be warrented.
Not sure who might have been against it; my take on it is at least that the build time cmake variables are tricky, when e.g. one clang binary might be for multiple different targets (e.g. for native compilation on linux, with per-target runtime directories there, but also for cross compilation for windows targets with a different setup for the target runtimes). I'm not against them, as long as both setups remain usable though.
https://github.com/llvm/llvm-project/pull/89775
More information about the cfe-commits
mailing list