mstorsjo wrote:

> > 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.
> 
> This matches my understanding. I am not aware of the embedded directive? Do 
> you embed a path to a compiler-rt library to the generated object files?

Clang does this, in a number of cases. In the MSVC ecosystem, one usually 
invokes `link` or `lld-link` directly, instead of using `clang` to drive the 
link - therefore, in order to pass implicit libraries to link, like 
asan/profile, directives are embedded into the generated object files, that 
tells the linker to link in those libraries.

> I think while technically a new clang can use an old compiler-rt file 
> hierarchy, technically it is unsupported: kinda like that a very old libc++ 
> may not be built with a new Clang.

I don't think anybody is arguing that a new clang should use an old compiler-rt 
install, but it should be able to use a new install with the layout according 
to `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` disabled.

> If we avoid hard-coded library names in compiler-generated relocatable files 
> (just called "object files" on Windows?). there should be no distributed 
> build system concern.

We can't avoid this - we already have this situation. See 
https://github.com/llvm/llvm-project/pull/87866#issuecomment-2072626122 - 
#87866 changed the output of the embedded directives when building with a 
distributed build system, where the compiler doesn't have access to inspect the 
lib directory that is going to be used to link things in the end.

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