At Mon, 3 May 2010 09:30:08 +0200, Francesco P. Lovergine wrote: > > On Sun, May 02, 2010 at 10:24:17PM +0200, Jeroen Dekkers wrote: > > Package: libgdal1-1.6.0 > > Version: 1.6.3-3+b2 > > Severity: normal > > Tags: patch > > > > I'm getting the following error: > > > > ERROR 6: Unable to load PROJ.4 library (libproj.so), creation of > > OGRCoordinateTransformation failed. > > > > This is because GDAL tries to dlopen libproj.so, but it should dlopen > > libproj.so.0. I tested the attached patch and that fixes the error. > > > > This is a non-sense: > > fran...@blegrez:~$ ldd /usr/lib/libgdal1.6.0.so|grep proj > libproj.so.0 => /usr/lib/libproj.so.0 (0xb4e70000) > > So, _what_ are you doing _exactly_ to get this type of error?
But that's because libogdi.so.3 links with libproj: runge:~% objdump -x /usr/lib/libogdi.so.3 | grep NEEDED NEEDED libdl.so.2 NEEDED libz.so.1 NEEDED libexpat.so.1 NEEDED libproj.so.0 NEEDED libm.so.6 NEEDED libc.so.6 libgdal1.6.0.so.1 doesn't link directly to it: runge:~% objdump -p /usr/lib/libgdal1.6.0.so.1 | grep NEEDED NEEDED libgeos_c.so.1 NEEDED libsqlite3.so.0 NEEDED libodbc.so.1 NEEDED libodbcinst.so.1 NEEDED libexpat.so.1 NEEDED libxerces-c.so.28 NEEDED libjasper.so.1 NEEDED libhdf5.so.6 NEEDED libmfhdfalt.so.0 NEEDED libdfalt.so.0 NEEDED libogdi.so.3.2 NEEDED libgif.so.4 NEEDED libjpeg.so.62 NEEDED libpng12.so.0 NEEDED libnetcdf.so.4 NEEDED libpq.so.5 NEEDED libz.so.1 NEEDED libpthread.so.0 NEEDED librt.so.1 NEEDED libdl.so.2 NEEDED libcurl-gnutls.so.4 NEEDED libmysqlclient.so.16 NEEDED libstdc++.so.6 NEEDED libgcc_s.so.1 NEEDED libm.so.6 NEEDED libc.so.6 As far as I understand because GDAL only needs libproj for doing certain kind of conversions. So it does a dlopen() when it needs it, but uses libproj.so instead of libproj.so.0. I found the bug when using the GIS part of django with the OpenStreetMap widget, so that's a bit of a complex test case. But I've also found a bug report for Fedora and they patched it the same way, see http://cvs.fedoraproject.org/viewvc/rpms/gdal/F-13/gdal.spec?revision=1.74&view=markup line 170. If you look at the source, ogr/ogrct.cpp is doing pfn_pj_init = (projPJ (*)(int, char**)) CPLGetSymbol( pszLibName, "pj_init" ); where pszLibName is set to libproj.so earlier in the code, and CPLGetSymbol is a platform independent wrapper defined in port/cplgetsymbol.cp that calls dlopen/dlsym. And that's clearly wrong, as it should always open libproj.so.0. And not just because libproj.so only exists in the libproj-dev package, but if libproj gets a SONAME bump because of an ABI change you would get a library with a different ABI if you dlopen just libproj.so. I hope this explanation clears everything up. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
