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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to