> OK, I recompiled gdal-2.2.4 --with-static-proj4 and got
> 
> ldd libgdal.so | grep proj
>     libproj.so.13 => /usr/local/lib64/libproj.so.13 (0x00007fe2ff181000)
>     libproj.so.12 => /lib64/libproj.so.12 (0x00007fe2f31c7000)
> ???
> 
> gdalinfo now runs fine and produces expected results.
> 
> I'm still concerned about the output of ldd libgdal.so

Yes that's not sane. That means that GDAL links to a library that links to the 
system libproj (/lib64/libproj.so.12), whereas GDAL directly links to your 
custom libproj 5 build ( /usr/local/lib64/libproj.so.13) . That may crash as 
well.
As proj 5.0.1 is (I believe) ABI compatible with previous releases, one 
potential hack is to make
sudo ln -s /usr/local/lib64/libproj.so.13 /usr/local/lib64/libproj.so.12
and define LD_LIBRARY_PATH to point to /usr/local/lib64/
A cleaner solution would be to identify the GDAL dependenci(es) that link to  
/lib64/libproj.so.12 and rebuild them against the one in  /usr/local/lib64/
libproj.so.13

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to