[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