Skip to content

GDAL lib version can conflict #481

@emlys

Description

@emlys

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions