macOS / MacPorts => dyld: Library not loaded: /usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib

[Robert-M-Muench]

I use MacPorts and it seems gitui is using some hardcoded/linked paths that don't fit:

% gitui
dyld: Library not loaded: /usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib
  Referenced from: /usr/local/bin/gitui
  Reason: image not found
zsh: abort      gitui

% fd libssl /opt/local
/opt/local/lib/libssl.1.1.dylib
/opt/local/lib/libssl.a
/opt/local/lib/libssl.dylib

% otool -L /usr/local/bin/gitui
/usr/local/bin/gitui:
	/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/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
	/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

Any chance to have a binary without hardcoded paths? Or is it best to compile from source?

[extrawurst]

a) I never heard of macports (TIL) - I guess its something like homebrew?
b) I was not aware someone uploaded gitui to it.
c) in fact I cannot find it there, do you have a link? (see https://ports.macports.org/?search=gitui&search_by=name)

any idea what version you might have gotten? it smells old, since we started vendoring openssl in the binary a while ago.

so I see two solutions:

1. get it from homebrew - those versions we officially update with each release
2. build from source :)

[Robert-M-Muench]

a) Yes

b & c) Nobody did, I mentioned MacPorts because I install(ed) OpenSSL using it, and MacPorts seems to use different paths than Homebrew.

I built from source and here you can see the dependencies of the final binary:

otool -L /Users/robby/.cargo/bin/gitui
/Users/robby/.cargo/bin/gitui:
	/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 59754.100.106)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1775.118.101)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
	/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

As you can see there is no reference to OpenSSL in my compiled version. So, maybe it's not needed? Or am I missing something?

[extrawurst]

As you can see there is no reference to OpenSSL in my compiled version. So, maybe it's not needed? Or am I missing something?

well it is correct that the binary should not even link a openssl dylib. I wonder why only our release binaries we have in the release tags here have this.

[extrawurst]

the plot thickens: the ci uses the new resolver (resolver = "2") and only then the openssl vendoring seems broken.

[extrawurst]

I found a workaround for this: adding the openssl-sys dependency right into gitui and force the vendoring feature on the top level. this seems to work. but there seems to be a issue in the new resolver here.

fixed in #775

[extrawurst]

@Robert-M-Muench thanks for reporting this, it actually uncovered quiet some oddities with rust/cargo

[Robert-M-Muench]

Glad it helped to find the problem and thanks for picking this up that quick.