<div dir="ltr"><div><div><div><div><div><br><br>On Sun, Apr 15, 2018 at 10:07 PM, Even Rouault &lt;<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>&gt; wrote:<br>&gt;<br>&gt; &gt; OK, I recompiled gdal-2.2.4 --with-static-proj4 and got<br>&gt; &gt;<br>&gt; &gt; ldd libgdal.so | grep proj<br>&gt; &gt;     libproj.so.13 =&gt; /usr/local/lib64/libproj.so.13 (0x00007fe2ff181000)<br>&gt; &gt;     libproj.so.12 =&gt; /lib64/libproj.so.12 (0x00007fe2f31c7000)<br>&gt; &gt; ???<br>&gt; &gt;<br>&gt; &gt; gdalinfo now runs fine and produces expected results.<br>&gt; &gt;<br>&gt; &gt; I&#39;m still concerned about the output of ldd libgdal.so<br>&gt;<br>&gt; Yes that&#39;s not sane. That means that GDAL links to a library that links to the<br>&gt; system libproj (/lib64/libproj.so.12), whereas GDAL directly links to your<br>&gt; custom libproj 5 build ( /usr/local/lib64/libproj.so.13) . That may crash as<br>&gt; well.<br>&gt; <br>&gt; As proj 5.0.1 is (I believe) ABI compatible with previous releases, one<br>&gt; potential hack is to make<br>&gt; sudo ln -s /usr/local/lib64/libproj.so.13 /usr/local/lib64/libproj.so.12<br>&gt; and define LD_LIBRARY_PATH to point to /usr/local/lib64/<br>&gt; A cleaner solution would be to identify the GDAL dependenci(es) that link to <br>&gt; /lib64/libproj.so.12 and rebuild them against the one in  /usr/local/lib64/<br>&gt; libproj.so.13<br><br></div>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.<br></div></div><br></div>Thanks a lot for your help!<br><br></div>Markus M<br><div><div><br></div></div></div>