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.

Sign up for GitHub

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

Jump to bottom

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

Open
ysmilda opened this issue Sep 9, 2024 · 5 comments · May be fixed by #4221
Open

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

ysmilda opened this issue Sep 9, 2024 · 5 comments · May be fixed by #4221
Assignees
@danopernis
Labels
bug Something isn't working. good first issue Good first issue for new developers.

Comments

@ysmilda
Copy link
Contributor

ysmilda commented Sep 9, 2024 •
edited
Loading

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 ysmilda added the bug Something isn't working. label Sep 9, 2024
@ysmilda
Copy link
Contributor Author

ysmilda commented Sep 9, 2024

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 danopernis added the good first issue Good first issue for new developers. label Sep 16, 2024
@danopernis
Copy link
Member

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)

@danopernis danopernis self-assigned this Sep 16, 2024
@ysmilda
Copy link
Contributor Author

ysmilda commented Sep 16, 2024

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
Copy link
Member

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 ysmilda linked a pull request Sep 24, 2024 that will close this issue
Draft
@ysmilda
Copy link
Contributor Author

ysmilda commented Sep 24, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@danopernis danopernis

Labels
bug Something isn't working. good first issue Good first issue for new developers.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Cleanup dependencies ysmilda/Prusa-Firmware-Buddy
2 participants
@danopernis @ysmilda