Skip to content
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

Open
xtexChooser opened this issue Nov 23, 2024 · 0 comments
Open

[clang] clang -M should print expanded paths #117438

xtexChooser opened this issue Nov 23, 2024 · 0 comments
Labels
clang Clang issues not falling into any other category

Comments

@xtexChooser
Copy link

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.

xtex@xtex1 ~ (main)> cat test.cpp
#include <cstdio>

int main() { return 0; }
xtex@xtex1 ~ (main)> clang -M test.cpp
test.o: test.cpp \
  /bin/../lib64/gcc/x86_64-aosc-linux-gnu/13.2.0/../../../../include/c++/13.2.0/cstdio \
  /bin/../lib64/gcc/x86_64-aosc-linux-gnu/13.2.0/../../../../include/c++/13.2.0/x86_64-aosc-linux-gnu/bits/c++config.h \
  /bin/../lib64/gcc/x86_64-aosc-linux-gnu/13.2.0/../../../../include/c++/13.2.0/pstl/pstl_config.h \
  /usr/include/tbb/tbb.h /usr/include/stdio.h \
  /usr/include/bits/libc-header-start.h \
  /usr/lib/clang/18/include/stdarg.h \
(some paths are emitted)
@github-actions 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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang Clang issues not falling into any other category
Projects
None yet
Development

No branches or pull requests

1 participant