-
Notifications
You must be signed in to change notification settings - Fork 12.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[clang] clang -M should print expanded paths #117438
Labels
clang
Clang issues not falling into any other category
Comments
github-actions
bot
added
the
clang
Clang issues not falling into any other category
label
Nov 23, 2024
xtexChooser
added a commit
to xtexChooser/llvm-project
that referenced
this issue
Nov 23, 2024
This fixes llvm#117438. If paths in dependency file are not absoulte, make (or ninja) will canonicalize them. While their canonicalization does not involves symbolic links expansion (for IO performance concerns), leaving a non-absolute path in dependency file may lead to unexpected canonicalization. For example, '/a/../b', where '/a' is a symlink to '/c/d', it should be '/c/b' but make (and ninja) canonicalizes it as '/b', and fails for file not found. Signed-off-by: Bingwu Zhang <[email protected]>
xtexChooser
added a commit
to xtexChooser/llvm-project
that referenced
this issue
Nov 24, 2024
This fixes llvm#117438. If paths in dependency file are not absoulte, make (or ninja) will canonicalize them. While their canonicalization does not involves symbolic links expansion (for IO performance concerns), leaving a non-absolute path in dependency file may lead to unexpected canonicalization. For example, '/a/../b', where '/a' is a symlink to '/c/d', it should be '/c/b' but make (and ninja) canonicalizes it as '/b', and fails for file not found. Signed-off-by: Bingwu Zhang <[email protected]>
xtexChooser
added a commit
to xtexChooser/llvm-project
that referenced
this issue
Nov 24, 2024
This fixes llvm#117438. If paths in dependency file are not absoulte, make (or ninja) will canonicalize them. While their canonicalization does not involves symbolic links expansion (for IO performance concerns), leaving a non-absolute path in dependency file may lead to unexpected canonicalization. For example, '/a/../b', where '/a' is a symlink to '/c/d', it should be '/c/b' but make (and ninja) canonicalizes it as '/b', and fails for file not found. Signed-off-by: Bingwu Zhang <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When using
clang -M
, some c++ standard library headers' paths are not real paths.For example, on AOSC OS (a usr-merged Linux distribution),
/bin/../lib64/gcc/
... are emitted. These paths are valid for IO operations (/bin
is linked to/usr/bin
on usr-merged distributions, thus/bin/../lib64
is equivalent to/usr/lib64
), but not for Make and Ninja. Both make and ninja canonicalize them to/lib64
, which does not exist, and they always regards these targets as dirty and rebuilds them everytime.The text was updated successfully, but these errors were encountered: