[gdal-dev] self-compiled gdal linking to old already-remove proj libs

[Even Rouault]

Andreas,

Several advice:

- if you do several builds from the same checkout of GDAL that you refresh with "git pull", 
make sure to 'make clean' before rebuilding

- the multiple links to libproj.so.X probably come from other dependencies of GDAL that try 
to link against the older versions (libproj.so.12) or the system one (libproj.so.15). Spatialite is 
a typical candidate. You also need to rebuild them against the updated PROJ

- remove the libproj-dev package to minimize the risks of linking agains the system /usr/lib/
x86_64-linux-gnu/libproj.so.15 (or temporary do a rename of
/usr/lib/x86_64-linux-gnu/libproj.so to /usr/lib/x86_64-linux-gnu/libproj.so.disabled)

- due to the potentially big numbers of libraries GDAL link to, and some system paths being 
put in the linking line (-L/usr/lib/x86_64-linux-gnu ), you may want to edit GDALmake.opt 
after ./configure to remove manually occurences of "-L/usr/lib/x86_64-linux-gnu "

- in the LIBS = line (at line 36 of GDALmake.opt), you may replace the -lproj (that can be 
influenced by previous -L paths) with the direct .so name, e.g /usr/local/lib/libproj.so.19, to 
control precisely the lib you want to link against (but probably only works on a ./configure --
without-libool GDAL build)

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200516/9feedb4e/attachment-0001.html>