[clang] [clang][driver] Prevent clang picking the system headers when started via a symlink (PR #68091)

Martin Storsjö via cfe-commits cfe-commits at lists.llvm.org
Thu Oct 5 00:40:43 PDT 2023


mstorsjo wrote:

> > ... I understand this is only a bug on MacOS?
> 
> I'm using clang only to compile my binary packages on macOS (the Linux binaries are compiled with gcc), so I got bitten by this bug only on macOS. The other platforms/targets may or may not be affected, I don't know; but my initial search for InstalledDir showed multiple references not paired with references to Dir.

This is one of the issues I have with mainly with the problem formulation - as there are two levels of logic involved here. The generic code which sets the install dir, and the target specific files in clang/lib/Driver/ToolChains, which do various things based on the install dir that has been detected elsewhere, plus target specific heuristics for falling back on other ways to detecting things that are needed.

If the installation dir is detected as the wrong thing, this would be fatal for all targets, but the exact behaviour you'd see would be quite target dependent. That's why explanations like "silently using system headers from a different version is hard to debug here" are out of scope here; using the wrong install dir is fatal of course.

If the darwin specific fallback handling could be improved, that'd of course be great.


On the other hand - in principle I kinda agree that the fix itself, locating things based on the actual executable, sounds like the right thing to do in any case. We're early in the 18.x cycle, and if we could get the tests fixed to work despite that, we'd have lots of time to see if someone is affected negatively by it, before 18.x is released.

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


More information about the cfe-commits mailing list