On Sun, Apr 15, 2018 at 10:07 PM, Even Rouault <even.roua...@spatialys.com> wrote: > > > 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
Not too many on my test system. So far, GDAL is working for me now with PROJ-5.0.x. If I encounter any problems later on, I will heed your advice. Thanks a lot for your help! Markus M
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
