If a pygeoprocessing wheel is installed in an environment with a different version of libgdal than it was built against, importing the compiled modules will fail with an error like
ImportError: dlopen(/Users/emily/miniforge3/envs/test/lib/python3.14/site-packages/pygeoprocessing/geoprocessing_core.cpython-314-darwin.so, 0x0002): Library not loaded: @rpath/libgdal.36.dylib
Referenced from: <0695A1F7-F0B6-388C-AE40-6A1791BBA087> /Users/emily/miniforge3/envs/test/lib/python3.14/site-packages/pygeoprocessing/geoprocessing_core.cpython-314-darwin.so
Reason: tried: '/Users/emily/miniforge3/envs/test/lib/libgdal.36.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/emily/miniforge3/envs/test/lib/libgdal.36.dylib' (no such file), '/Users/emily/miniforge3/envs/test/lib/libgdal.36.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/emily/miniforge3/envs/test/lib/libgdal.36.dylib' (no such file), '/Users/emily/miniforge3/envs/test/bin/../lib/libgdal.36.dylib' (no such file), '/Users/emily/miniforge3/envs/test/bin/../lib/libgdal.36.dylib' (no such file)
This is the same as what's happening in natcap/invest#2206, and I propose fixing in the same way as I described in this PR.
If a pygeoprocessing wheel is installed in an environment with a different version of libgdal than it was built against, importing the compiled modules will fail with an error like
This is the same as what's happening in natcap/invest#2206, and I propose fixing in the same way as I described in this PR.