[DebianGIS-dev] Bug#579989: Bug#579989: Tries to dlopen libproj.so instead of libproj.so.0

[Jeroen Dekkers]

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:
> 
> frankie at 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