debian libproj dynamic load issue

[thehesiod]

we noticed that when ogr tries to dynamically load libproj it tries to load libproj.so instead of libproj.so.XX. This means that both the client needs to install libproj-dev and it may try to load the wrong version that doesn't work. If gdal is built against a particular libproj.so it should load the specific version and not the -dev version. Here's the callstack from python:

#1  0x00007ffff606697e in CPLGetSymbol () from /usr/local/lib/libgdal.so.20
#2  0x00007ffff580dd63 in ?? () from /usr/local/lib/libgdal.so.20
#3  0x00007ffff580eb05 in OCTProj4Normalize () from /usr/local/lib/libgdal.so.20
#4  0x00007ffff57ff473 in OGRSpatialReference::importFromProj4(char const*) () from /usr/local/lib/libgdal.so.20
#5  0x00007fffe961a1da in OSRSpatialReferenceShadow_ImportFromProj4 (ppszInput=<optimized out>, self=0x617e40) at extensions/osr_wrap.cpp:4080
#6  _wrap_SpatialReference_ImportFromProj4 (args=<optimized out>) at extensions/osr_wrap.cpp:13442
#7  0x00007ffff79a3629 in PyCFunction_Call () from /usr/local/lib/libpython3.5m.so.1.0
#8  0x00007ffff79d55e9 in PyEval_EvalFrameEx () from /usr/local/lib/libpython3.5m.so.1.0
#9  0x00007ffff79d70ad in ?? () from /usr/local/lib/libpython3.5m.so.1.0
#10 0x00007ffff79d32c1 in PyEval_EvalFrameEx () from /usr/local/lib/libpython3.5m.so.1.0
#11 0x00007ffff79d70ad in ?? () from /usr/local/lib/libpython3.5m.so.1.0
#12 0x00007ffff79d7183 in PyEval_EvalCodeEx () from /usr/local/lib/libpython3.5m.so.1.0
#13 0x00007ffff79d71ab in PyEval_EvalCode () from /usr/local/lib/libpython3.5m.so.1.0
#14 0x00007ffff79e3dce in PyRun_FileExFlags () from /usr/local/lib/libpython3.5m.so.1.0
#15 0x00007ffff79e5146 in PyRun_SimpleFileExFlags () from /usr/local/lib/libpython3.5m.so.1.0
#16 0x00007ffff7aa51e4 in Py_Main () from /usr/local/lib/libpython3.5m.so.1.0
#17 0x0000000000400ad6 in main ()

btw I'm not sure if I logged this against the correct component.

[Even Rouault]

You can build --with-static-proj4 to avoid that (as the name doesn't suggest, if a .so exists, it will link against it). This is indeed a known issue, that could be removed by dropping support for proj dynamic loading, as I suggested in #6882

Closing as a kind of "duplicate" of #6882