[BUG] Bundled version of clang-format broken on ARM Apple devices

[ysmilda]

Describe the bug

When committing pre-commit hangs at the clang-format stage indefinitely. When running the command ./.dependencies/clang-format-16-83817c2f/clang-format (as defined in the .pre-commit-config.yaml) we get the following output:

dyld[30989]: Library not loaded: /usr/local/opt/zstd/lib/libzstd.1.dylib
  Referenced from: <B970F465-3A4F-3100-ADE2-CBA39DB5AB8E> /Users/yorick/Developer/Personal/Prusa-Firmware-Buddy/.dependencies/clang-format-16-83817c2f/clang-format
  Reason: tried: '/usr/local/opt/zstd/lib/libzstd.1.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/zstd/lib/libzstd.1.dylib' (no such file), '/usr/local/opt/zstd/lib/libzstd.1.dylib' (no such file), '/usr/local/lib/libzstd.1.dylib' (no such file), '/usr/lib/libzstd.1.dylib' (no such file, not in dyld cache)

clang-format@16 expects the libzstd.1.dylib to be at a different location than where clang-format@18 expects it (there where brew installs it). Creating a symlink as suggested in this thread proved no solution as the bundled clang-format expects a x86 version, and not the now default arm64 version.

'/usr/local/lib/libzstd.1.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64'))

Changing the .pre-commit-config.yaml hooks entry with id clang-format to the settings below allows the pre-commit hook to run. This makes it use the version installed via brew install clang-format.

      entry: clang-format
      language: system

The solution would be to update the clang-format dependency to a later version.

How to reproduce

Clone the repo on an Apple device with an ARM processor. Make a commit and run the pre-commit command.

[ysmilda]

A temporary fix that can be used is copying the new version over the old version, this way commits can still be made.

cp $(where clang-format) ./.dependencies/clang-format-16-83817c2f/clang-format

[danopernis]

Hello @ysmilda most of us don't have Apple devices. I talked to the one developer who does and he basically used the same workaround as you. That being said, we will gladly accept PR which will fix this situation. We are quite dissatisfied with current state of affairs, when we are using some old binaries downloaded from our AWS bucket and would prefer more up-to-date binaries from official sources (like github)

[ysmilda]

I wouldn't mind having a look at replacing these self hosted dependencies. I wasn't sure if there was a specific reason behind staying at those versions.

[danopernis]

No specific reason. From what I gathered, at that time it was easier to host these as there were no official options and since then there was no reason to replace them.

[ysmilda]

I see why it was easier to host them and keep them stable. For clang/llvm I couldn't find a proper source of the separate binaries except for the archives in the LLVM releases. I build a simple repository that acts as a mirror for the extracted binaries.

Still some problems with using the gcc-arm-none-eabi from macOS ARM devices. Will keep working on those.