> 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. >
Ok, thanks. Solved in the 1.7.2 branch on svn, due in a few for experimental. The reason for skipping by default a usual shlib linking is quite obscure to me, but that can be better managed by configure. I suspect that is done to avoid depending strictly on a specific SONAME, because proj4 API is frozen since ages, but anyway that's not the way things are done on Debian. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
