Incompatibilities when using GMT macOS bundle from the externals

[PaulWessel]

Description of the problem

The general issue here is the problem of Matlab, Julia, and Python finding the right GMT libraries and dependencies. For the GMT/MEX toolbox the only way I could fix this for macOS was to rename shared libraries with the share/tools/gmt_prepmex.sh which creates a new libgmt.dylib and set of dependencies with different names than what Matlab expects (i.e., libXnetcdf instead of libnetcdf). This is an awkward solution fueled by general ignorance, but it does seem to work.

Another option to be explored is the use of the environmental setting LD_PRELOAD which may possibly help us list the required dependencies we want to avoid a dependency conflict with the loading program. Looking at libgmt.dylib on macOS, I see this list of non-GMT shared libraries:

/opt/local/lib/libnetcdf.19.dylib (compatibility version 19.0.0, current version 19.0.0)
	/opt/local/lib/libcurl.4.dylib (compatibility version 12.0.0, current version 12.0.0)
	/opt/local/lib/libgdal.29.dylib (compatibility version 30.0.0, current version 30.1.0)
	/opt/local/lib/libgeos_c.1.dylib (compatibility version 16.0.0, current version 16.2.0)
	/opt/local/lib/libpcre.1.dylib (compatibility version 4.0.0, current version 4.13.0)
	/opt/local/lib/libfftw3f.3.dylib (compatibility version 10.0.0, current version 10.10.0)
	/opt/local/lib/libfftw3f_threads.3.dylib (compatibility version 10.0.0, current version 10.10.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)

If one does set export LD_PRELOAD=/opt/local/lib/libnetcdf.19.dylib:/opt/local/lib/libcurl.4.dylib:..., do we also need to add the (long) list of dependencies that these libraries need (e.g., proj for gdal etc)?

[maxrjones]

xref:

• macOS bundle doesn't work for pygmt #1930

[PaulWessel]

Yes so the above cross-ref does have the solution, apparently, but we never actually tried to make this work in the bundle building itself.

[joa-quim]

Don't know. The problem is that damn @executable_path/ that seems to be interpreted literally by the loadlibrary in Julia

[joa-quim]

We are very aeare of this but we also don't know how to solve this.