[geos-devel] 3.3.4 Released
gdt at ir.bbn.com
Tue Jun 5 07:56:33 PDT 2012
Sandro Santilli <strk at keybit.net> writes:
> On Mon, Jun 04, 2012 at 04:06:20PM -0400, Greg Troxel wrote:
OK, understood about ABI being unstable, and will try to send a patch.
It sounds like then that geos considers any direct use or linking of the
C++ library to be a bug on the part of the using package.
>> Is this part of a plan to make it difficult to use the C++ library? If
>> so, I would say that it's not working, because it makes life difficult
>> for packagers rather than making it difficult for people who release
>> code that uses the C++ library (postgis and gdal both seem to do that,
>> or at least they are linked that way on my system - perhaps that's a
>> configure/packaging bug?).
> That's a packaging bug. Both PostGIS and GDAL only use the C-API, so they
> should not be packaged as being dependent on the C++ one. So all clients
> should depend on libgeos_c, and _only_ libgeos_c should depend on
Sorry, I was fooled by ldd's recursive listing (which is sort of right)
which for reasons I don't understand doesn't indent libraries required
by other libraries. objdump -x shows that indeed postgis (1.5) depends
on geos_c only:
But libgdal (1.9.1) has a NEEDED line for libgeos-3.3.4:
If anyone can run objdump -x on libgdal on some other system and tell me
if libgeos appears, I'd appreciate it. During the build (under pkgsrc)
I see an explicit libgeos on the link line, but I haven't yet been able
to untangle the make variables to figure out why. I read the packaging
control files for gdal-lib and I don't see anything that tries to mess
with how it finds geos, so my first guess is that whatever is happening
isn't a pkgsrc issue, but it's really hard to tell.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 194 bytes
Desc: not available
More information about the geos-devel