[PATCH] D37954: Try to shorten system header paths when using -MD depfiles
Peter Wu via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Oct 23 15:57:16 PDT 2017
Lekensteyn added a comment.
(FWIW, the suggestion to use `FileManager:getCanonicalName` did not work because I have no DirectoryEntry. And `-no-canonical-prefixes` it used very early and stripped from normal options, it seems used for a different purpose. Given the opposition, I think that this patch is a no-go.)
In https://reviews.llvm.org/D37954#902979, @jyknight wrote:
> It seems to me that it was caused by the prefix being set as "/bin" instead of "/usr/bin", because clang _doesn't_ actually canonicalize its prefix, even when -no-canonical-prefixes isn't specified! All it does, now, is to make the prefix absolute -- without fully canonicalizing. I think that's simply a bug.
> If the prefix had been, properly, /usr/bin, then the include path would've been:
> And in that case, it would've worked properly with ninja, without adding the feature in this patch.
> Reference clang/tools/driver/driver.cpp:297:
> // FIXME: We don't actually canonicalize this, we just make it absolute.
> if (CanonicalPrefixes)
If this fixes the issue, then it would definitely be a much better approach. If this has changed between Clang 4 -> 5, then it is possible the root cause.
On my system (Arch Linux) `/bin` is a symlink to `usr/bin`. Output of `clang -v`:
clang version 5.0.0 (tags/RELEASE_500/final)
Thread model: posix
Found candidate GCC installation: /bin/../lib/gcc/x86_64-pc-linux-gnu/7.2.0
Found candidate GCC installation: /bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/7.2.0
Selected GCC installation: /bin/../lib64/gcc/x86_64-pc-linux-gnu/7.2.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
More information about the cfe-commits