MacOS runners fail with clang versions 15-18
2bndy5 opened this issue · comments
Currently, if the MacOS runner does not have the requested version of clang tools installed, then cpp-linter/clang-tools-pip will install statically compiled binaries. However, versions of clang-format v15-v18 are suffering a segmentation fault due to the static binaries used.
full traceback from recent CI run
Traceback (most recent call last):
File "/Users/runner/work/cpp-linter-action/cpp-linter-action/venv/bin/cpp-linter", line 8, in <module>
sys.exit(main())
File "/Users/runner/work/cpp-linter-action/cpp-linter-action/venv/lib/python3.10/site-packages/cpp_linter/__init__.py", line 81, in main
(format_advice, tidy_advice) = capture_clang_tools_output(
File "/Users/runner/work/cpp-linter-action/cpp-linter-action/venv/lib/python3.10/site-packages/cpp_linter/clang_tools/__init__.py", line 117, in capture_clang_tools_output
show_tool_version_output(format_cmd)
File "/Users/runner/work/cpp-linter-action/cpp-linter-action/venv/lib/python3.10/site-packages/cpp_linter/clang_tools/__init__.py", line 108, in show_tool_version_output
version_out = subprocess.run(
File "/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/subprocess.py", line 526, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['/Users/runner/work/cpp-linter-action/cpp-linter-action/venv/bin/clang-format-15', '--version']' died with <Signals.SIGABRT: 6>.
The only alternative installation approach that I can think of for MacOS is installing the full LLVM package via homebrew. Maybe there's a better solution though, I have not researched this thoroughly.
That is a viable alternative solution than fixing the segmentation fault in https://github.com/cpp-linter/clang-tools-static-binaries in a short time.
Right now macOS builds with clang versions are all success, but Linux builds are failed with versions 14-18.
https://github.com/cpp-linter/clang-tools-static-binaries/actions/runs/9012842234
UPDATE: maybe the above runs take too long to reach time out, I will disable other builds and only build with version 14~18.
I'm also noticing variations of the following warning in the CI logs:
warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
This is related to the segmentation fault problems on Linux since a certain version of glibc is required to be present on the system (for a statically linked binary).
Using the homebrew idea is not fool-proof. It doesn't provide all major version of LLVM that this action supports.
Warning: No available formula with the name "llvm@10". Did you mean llvm, llvm@17, llvm@16, llvm@15, llvm@14, llvm@13, llvm@12, llvm@11, llvm@9 or llvm@8?
See this CI run for the various errors/warnings reported by homebrew.
Apparently LLVM 15 is already installed on macos-latest runners. However, clang-tools-pip pkg fails to find the clang tools' binaries and installs the faulty static binary instead.
Apparently LLVM 15 is already installed on macos-latest runners. However, clang-tools-pip pkg fails to find the clang tools' binaries and installs the faulty static binary instead.
So, let's create this issue in the clang-tools-pip project?
A lot of suggestions on the internet recommend installing llvm from homebrew and manually sym-linking to the binary path
brew install llvm@15
ln -s "$(brew --prefix llvm@15)/bin/clang-format" "/usr/local/bin/clang-format-15"
ln -s "$(brew --prefix llvm@15)/bin/clang-tidy" "/usr/local/bin/clang-tidy-15"
Apparently Mac OS comes with LLVM and clang installed but not any of the clang tools. Adding homebrew-installed LLVM to PATH is discouraged because of likely conflicts with system-installed LLVM.
🎉 Manually sym-linking to homebrew-installed LLVM binaries indeed resolves this problem (for cpp-linter-action). See this PR's CI run
The seg fault problem should still be addressed separately in the static-binaries builds though.