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