Burn runpath/rpath into the compiled object

[snowman2]

Looking back at this experience, the runpath/rpath should be "burned" into the compiled object, so it does not rely on [DY]LD_LIBRARY_PATH variables. This is normally done using the linker flag:

export LDFLAGS="${LDFLAGS} -Wl,-rpath,/path/to/lib"

the resulting compiled object can be inspected in Linux with readelf -d file.so, and look for something like:

0x000000000000001d (RUNPATH)            Library runpath: [/path/to/lib]

or macOS with otool -l file.so, and look for something like:

Load command 15
          cmd LC_RPATH
      cmdsize 48
         path /usr/local/miniconda/envs/test/lib (offset 12)
Load command 16
          cmd LC_RPATH
      cmdsize 40
         path /path/to/lib (offset 12)

Using -Wl,-rpath,/path/to/lib should fix the "@rpath/libproj.22.dylib not found" issue for macOS. This is what is done here for shapely to link to libgeos.

Originally posted by @mwtoews in #44 (comment)

Thanks @mwtoews 👍

[snowman2]

I wonder why this is necessary with cmake and not with autotools?

[mwtoews]

Great question! I don't have a mac, so it's difficult and time-consuming to investigate, as I need to re-run GitHub Actions experiments. But generally it seems that an autotools build of the library somehow passes an absolute reference (e.g.) /tmp/proj_autoconf_install_from_dist_all/lib/libproj.22.dylib (from otool -L file.so), whereas a CMake build passes a relative reference @rpath/libproj.22.dylib, but needs the -rpath linker option to be specified. There are various CMake options to change or disable RPATH things on macOS to make it behave the same as the autotools build of the library, but I'm not sure what these are exactly, or if it's a good strategy. This should be resolved for PROJ sometime this month, so I'll drop any update here.

[snowman2]

@mwtoews, what do you recommend for #50 ?

[mwtoews]

As with OSGeo/PROJ#3009, edit config.sh in pre_build, after build_proj you may need something like:

export LDFLAGS="${LDFLAGS} -Wl,-rpath,somepath"

the big question is what to put for somepath. The absolute path is /Users/runner/work/pyproj-wheels/pyproj-wheels/pyproj/pyproj/proj_dir/lib. The shapely-2.0 builds for macOS use an absolute path to a GEOS build here. There is also a install_name_tool on macOS to modify dylib files. I've found working with macOS difficult without direct access to a machine -- although OSX-KVM is worth investigating.

[snowman2]

Thanks 👍

[mwtoews]

Glad it finally worked! I might need to repeat some of this info on the mail list, as I'd expect other macOS users/packagers to encounter this too.