macOS bundle doesn't work for pygmt

[seisman]

I believe it's a known issue and was reported somewhere, but I can't find it.

The macOS bundle works well for GMT command-line/scripts, but doesn't work for pygmt, and may also not work for GMT.jl.

This is what I get with pygmt:

GMTCLibNotFoundError: Error loading the GMT shared library '/Applications/GMT-6.0.0.app/Contents/Resources/lib/libgmt.dylib':
dlopen(/Applications/GMT-6.0.0.app/Contents/Resources/lib/libgmt.dylib, 6): Library not loaded: @executable_path/../lib/libcurl.4.dylib
  Referenced from: /Applications/GMT-6.0.0.app/Contents/Resources/lib/libgmt.dylib
  Reason: Incompatible library version: libgmt.dylib requires version 11.0.0 or later, but libcurl.4.dylib provides version 10.0.0

[joa-quim]

Yes, that issue started to be discussed here

[PaulWessel]

FYI: I pruned my laptop for brew and macports so it has nothing other than Apple bins. I installed the 6.0.0 pre-release bundle, and in a regular bash shell everything works as long as I added the bundle bin to PATH and set PROJ_LIB to bundle share/proj6. The gs works fine without any GS_LIB setting. SO while the bundle may need more work to serve Julia and Python, it will certainly be very helpful to non-Unix Mac users who just want to install and run without learning the full distribution way of life.

[seisman]

I try to make some changes to the macOS bundle using the following script, and then the bundle works well for CLI, PyGMT, and GMT.jl.

What the script does is simple. It replaces @executable_path to @loader_path in all the libraries.

cd /Applications/GMT-6.1.1.app/Contents/Resources/lib
for dylib in $(ls *.dylib); do
	otool -L $dylib | awk -v lib=$dylib '/^[[:blank:]]*@executable_path/ {printf("install_name_tool -change %s @loader_path/%s %s\n", $1, substr($1, 18), lib)}' | sh
done

for libso in $(ls gmt/plugins/*.so); do
	otool -L $libso | awk -v lib=$libso '/^[[:blank:]]*@executable_path/ {printf("install_name_tool -change %s @loader_path/../../%s %s\n", $1, substr($1, 18), lib)}' | sh
done

I also build gmtmex against the bundle, copy gmt.m and gmtmex.mexmaci64 to the bundle's bin directory, and change @executable_path to @loader_path in gmtmex.mexmaci64. Then the macOS bundle + gmtmex also work well.

So perhaps when we build the macOS bundle, we should use @loader_path, not @executable_path.

[PaulWessel]

Maybe the cpack command can control the loader/executable_path stuff? I think we are getting whatever default it has, no?

[seisman]

Perhaps line 192 determines executable_path for dylibs:

gmt/cmake/dist/CMakeLists.txt

Lines 187 to 199 in 81d4e56

	function(gp_item_default_embedded_path_override item default_embedded_path_var)
	# By default, embed items as set by gp_item_default_embedded_path:
	set(path \"\${\${default_embedded_path_var}}\")
	# Embed *.dylib in the lib folder:
	if(item MATCHES \"[.]dylib\$\")
	set(path \"@executable_path/../lib\")
	endif()
	set(\${default_embedded_path_var} \"\${path}\" PARENT_SCOPE)
	endfunction(gp_item_default_embedded_path_override)
	include (BundleUtilities)
	fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/${GMT_BINDIR}/gmt${CMAKE_EXECUTABLE_SUFFIX}\" \"\${CMAKE_INSTALL_PREFIX}/${GMT_LIBDIR}/gmt${CMAKE_EXECUTABLE_SUFFIX}/plugins/${GMT_SUPPL_LIB_NAME}.so\" \"\")
	endif ()

[PaulWessel]

It sure looks like that. I am reading https://wincent.com/wiki/%40executable_path%2C_%40load_path_and_%40rpath as well.