On Tue, Apr 30, 2024 at 9:18 AM Even Rouault <even.roua...@spatialys.com> wrote:
Even, > Also try in a Python interpreter "from osgeo import gdal" to see if the > exception is more verbose. If your GDAL lib links against libraries that > are not in the default library search path, GDAL command line utilities > might still be able to find them, but loading libgdal through the Python > bindings might fail (at least that happens to me on Linux, cf > https://github.com/OSGeo/gdal/pull/9783) > Also try otool -L on libgdal.dylib and on _gdal.cpython-312-darwin.so > This was indeed the issue. I didn't think there was a version of GDAL in my environment, but it must have gotten in by error at some point. When the SWIG library _gdal...so was created, a dependency was created for the system-located library (version 34) rather than the one in the build (version 35). I'd have to do more research to figure out how to rectify this, if desired. Thanks for your help. The python failure message wasn't too helpful on its own. -- Andrew Bell andrew.bell...@gmail.com
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
