foriequal0/git-trim

Does not work on MacOS when homebrew is not installed in the default location

kdheepak opened this issue · 7 comments

Check your version before submitting the bug

I downloaded the latest version from github releases.

$ git-trim
dyld: Library not loaded: /usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib
  Referenced from: /Users/USER/.zinit/plugins/foriequal0---git-trim/git-trim/git-trim
  Reason: image not found
zsh: abort      git-trim --version

Describe the bug

git-trim appears to require libssl in /usr/local/opt. This appears to be a homebrew dependency. On MacOS, homebrew may be installed in any location, and may not be in /usr/local/opt (although this is the most likely location).

Resolution

For MacOS, you can change the location of libraries.

Use otool -L git-trim to find locations of all dependencies.

$ otool -L ~/.zinit/plugins/foriequal0---git-trim/git-trim/git-trim
/Users/USER/.zinit/plugins/foriequal0---git-trim/git-trim/git-trim:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 59306.140.5)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0)
	/usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	/usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

Use install_name_tool -change old new to change paths. I believe the recommendation is to use @rpath to change them, but that didn't work for me. I instead used brew --prefix and used the full path from there.

$ install_name_tool -change /usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib $(brew --prefix)/opt/openssl@1.1/lib/libssl.1.1.dylib ~/.zinit/plugins/foriequal0---git-trim/git-trim/git-trim
$ install_name_tool -change /usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib $(brew --prefix)/opt/openssl@1.1/lib/libcrypto.1.1.dylib ~/.zinit/plugins/foriequal0---git-trim/git-trim/git-trim

Thanks for reporting the bug!
I think @rpath is the way how it should be in this case. But I'm worried about brew --prefix would break others.
Also I could add [profile] rpath = true in Cargo.toml, but the default value of rpath is false, and there isn't a viable way to selectively enable rpath = true only on macOS without passing a linker flags combo.
Unfortunately, I don't have a Mac to test it. Please let me know if you have a good fix for this.

Also it seems that someone voluntarily created a homebrew formula for git-trim. Would you try it instead?

Also it seems that someone voluntarily created a homebrew formula for git-trim. Would you try it instead?

Sure, I can try it. My brew is in a non standard location on my work machine, since I don't have permission to install in /usr/local/.

Unfortunately, I don't have a Mac to test it. Please let me know if you have a good fix for this.

Happy to do any testing you need on my mac. Just let me know what you need done!

I've tested some flags in Github Actions mac workers, however they didn't make any differences.
with rpath=true

target/debug/git-trim:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 59306.140.5)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0)
        /usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
        /usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
        /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

with rpath=false

target/debug/git-trim:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 59306.140.5)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0)
        /usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
        /usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
        /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

Also many linux distros discourages rpath for some reasons
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath
https://wiki.debian.org/RpathIssue
I think building it is the best we can.

I hadn't seen this rpath option before, and I don't think it should be necessarily used on linux. Can you run a post install script before packaging to run install_name_tool for macos?

Since I don't have a Mac (with a non-standard install path, or a standard one) to continuously check whether it works or not for future releases, it would be burdens to me to add some special commands for unusual configurations.
I'll stick to the default configuration, and instruct them to build themselves who has non-standard configurations.

Okay, thanks! I will close this issue.

For what it is worth, you can use a github action to update the homebrew formula when you make a release. That way, you can ensure the homebrew formula is updated automatically through a CI. You just have to add the following to your release workflow:

  homebrew:
    name: Bump Homebrew formula
    runs-on: macos-latest
    steps:
      - name: Update Homebrew formula
        if: startsWith(github.ref, 'refs/tags/')
        uses: dawidd6/action-homebrew-bump-formula@v3
        with:
          token: ${{secrets.HOMEBREW_TOKEN}}
          formula: git-trim