Skip to content

LLVM / Clang system config file setting breaks with -no-canonical-prefixes #220757

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

Open
4 tasks done
chandlerc opened this issue Apr 19, 2025 · 6 comments
Open
4 tasks done
Labels
help wanted Task(s) needing PRs from the community or maintainers upstream issue An upstream issue report is needed

Comments

@chandlerc
Copy link
Contributor

brew gist-logs <formula> link OR brew config AND brew doctor output

> brew config
HOMEBREW_VERSION: 4.4.31
ORIGIN: https://github.com/Homebrew/brew
HEAD: 0046519c08cd3967e0934c82195361ac7e76c567
Last commit: 5 days ago
Branch: stable
Core tap JSON: 19 Apr 21:14 UTC
Core cask tap JSON: 19 Apr 21:14 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_EDITOR: nvim
HOMEBREW_MAKE_JOBS: 10
Homebrew Ruby: 3.3.8 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.3.8/bin/ruby
CPU: deca-core 64-bit arm_firestorm_icestorm
Clang: 16.0.0 build 1600
Git: 2.39.5 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 15.4-arm64
CLT: 16.3.0.0.1.1742442376
Xcode: 16.2
Rosetta 2: false

> brew doctor
Your system is ready to brew.

Verification

  • My brew doctor output says Your system is ready to brew. and am still able to reproduce my issue.
  • I ran brew update and am still able to reproduce my issue.
  • I have resolved all warnings from brew doctor and that did not fix my problem.
  • I searched for recent similar issues at https://github.com/Homebrew/homebrew-core/issues?q=is%3Aissue and found no duplicates.

What were you trying to do (and why)?

Use clang with the flag -no-canonical-prefixes, which results in generally better paths by preserving useful symlinks, and has worked for many years.

What happened (include all command output)?

> echo "int main() {}" | clang -c -o test.o -x c -

> clang -o test test.o -v
Homebrew clang version 20.1.3
Target: arm64-apple-darwin24.4.0
Thread model: posix
InstalledDir: /opt/homebrew/Cellar/llvm/20.1.3/bin
Configuration file: /opt/homebrew/etc/clang/arm64-apple-darwin24.cfg
System configuration file directory: /opt/homebrew/etc/clang
User configuration file directory: /Users/chandlerc/.config/clang
 "/usr/bin/ld" -demangle -lto_library /opt/homebrew/Cellar/llvm/20.1.3/lib/libLTO.dylib -dynamic -arch arm64 -platform_version macos 15.0.0 15.4 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -mllvm -enable-linkonceodr-outlining -o test test.o -lSystem /opt/homebrew/Cellar/llvm/20.1.3/lib/clang/20/lib/darwin/libclang_rt.osx.a

> clang -no-canonical-prefixes -o test test.o -v
Homebrew clang version 20.1.3
Target: arm64-apple-darwin24.4.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
System configuration file directory: /opt/etc/clang
User configuration file directory: /Users/chandlerc/.config/clang
 "/usr/bin/ld" -demangle -lto_library /opt/homebrew/opt/llvm/lib/libLTO.dylib -dynamic -arch arm64 -platform_version macos 15.0.0 15.0.0 -mllvm -enable-linkonceodr-outlining -o test test.o -lSystem /opt/homebrew/opt/llvm/lib/clang/20/lib/darwin/libclang_rt.osx.a
ld: library 'System' not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Note that in the failing execution the system configuration file directory becomes /opt/etc/clang instead of /opt/homebrew/etc/clang. The result is that it fails to find the configuration file and include the relevant SDK paths.

What did you expect to happen?

Both clang invocations should find the configuration directory and succeed.

Step-by-step reproduction instructions (by running brew commands)

The above should be a complete sequence of steps to reproduce. Requires having `llvm` installed.
@daeho-ro
Copy link
Member

homebrew clang binary is linked,

/opt/homebrew/opt/llvm/clang -> /opt/homebrew/opt/../Cellar/llvm/20.1.3/bin/clang

and config path is defined by relatively.

clang_config_file_dir.relative_path_from(bin)

When the path is simplified,

bin: /opt/homebrew/Cellar/llvm/20.1.3/bin
config: /opt/homebrew/etc/clang

clang_config_file_dir.relative_path_from(bin) = ../../../etc/clang

and -no-canonical-prefixes added,

bin: /opt/homebrew/opt/llvm
config: /opt/homebrew/opt/llvm/../../../etc/clang = /opt/etc/clang

the config path is now wrong.

@chandlerc
Copy link
Contributor Author

I'd suggest laying out the configuration etc directory as a sibling to the bin directory, and making the path of ../etc/clang work in both cases by symlinking /opt/homebrew/etc/clang to /opt/homebrew/opt/../Cellar/llvm/20.1.3/etc/clang parallel to the binary symlink.

Copy link
Contributor

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@github-actions github-actions bot added the stale No recent activity label May 12, 2025
@chandlerc
Copy link
Contributor Author

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

Not sure why this is stale -- this is a continuing issue that is breaking a specific use case. I have a workaround but that won't work forever. Would really like to see this get fixed.

@github-actions github-actions bot removed the stale No recent activity label May 12, 2025
@Bo98
Copy link
Member

Bo98 commented May 12, 2025

This definitely seems like an upstream bug as what we do is explicitly supported: https://github.com/llvm/llvm-project/blame/2e1809f94aa0f1c1fa0281d1351c0e0ea0bf06e3/clang/lib/Driver/Driver.cpp#L269-L278.

The bug seems to be that it assumes ClangExecutable is the original executable whereas with -no-canonical-prefixes this isn't true as it does a PATH search instead - which is impossible to generalise a full fix for on our side as the root it take the path relative to will change depending on how you set up your PATH. Though symlinking etc would indeed cover the most common setups as a partial workaround.

@Bo98 Bo98 added the upstream issue An upstream issue report is needed label May 12, 2025
@carlocab
Copy link
Member

Yes, this is an upstream bug. I'll try to find the time to send a patch.

@carlocab carlocab added the help wanted Task(s) needing PRs from the community or maintainers label May 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Task(s) needing PRs from the community or maintainers upstream issue An upstream issue report is needed
Projects
None yet
Development

No branches or pull requests

4 participants