[clang] [Driver] Ensure ToolChain::LibraryPaths is not empty for non-Darwin (PR #87866)

Martin Storsjö via cfe-commits cfe-commits at lists.llvm.org
Tue Apr 23 12:14:31 PDT 2024


mstorsjo wrote:

> > I would suggest we revert this - and at least collect all the observed side effects and declare them before considering relanding it.
> 
> That sounds good to me. Do you have a list of PRs to revert?

Not sure if there are follow-up fixes, sorry, but the discussed PRs are this one, and #81037 (where #89775 says the latter one changed functional behaviour, but it sounds mostly like your issue, i.e. caused by this one).

> > ... then we do still get the old name embedded.
> 
> Sure. The motivation on our side is a distributed compile service where the library doesn't exist on the remote end. This patch means we'll have to add knowledge about path layouts at link time to the remote setup at compile time. That's certainly doable, but kind of janky.

Right, I see. FWIW, with the embedding of directives, which kind of depends on knowing the runtime layout style, I guess this is an issue that needs to be tackled at one point or another, for distributed builds (especially as long as the intent is to change default towards the per-triple directories instead of per-os directories).

> (What we'll actually do is use the flag from #89642 to disable all this guessing of libs and just explicitly pass the path to the lib at link time. So this won't actually affect us then, but reverting and relanding in one commit with a list of side effects still sounds like a good thing independent of that.)

Ah, that probably sounds like a good flag to have in any case, for that kind of distributed setup!

https://github.com/llvm/llvm-project/pull/87866


More information about the cfe-commits mailing list