MacOS runners fail with clang versions 15-18

[2bndy5]

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.

[shenxianpeng]

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.

[shenxianpeng]

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.

[2bndy5]

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).

[2bndy5]

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.

[2bndy5]

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.

[shenxianpeng]

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?

[2bndy5]

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.

[2bndy5]

🎉 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.