[postgis-devel] liblwgeom symbols exported by postgis

[Sandro Santilli]

On Mon, Sep 28, 2015 at 05:58:55PM -0400, Paragon Corporation wrote:
> > What I found while developing https://github.com/strk/fineltra/ is
> > that the current static linking is actually already screwing things up
> > as you might hit functions of, say, PostGIS-1.5 while running
> > functions of PostGIS-2.2. In my case it was "lwpoint_construct" of
> > PostGIS-1.5 being called by "lwpoint_from_wkb_state" of another.
> > See https://trac.osgeo.org/postgis/ticket/3281
> 
> Strk I'm not following you here?
> 
> 1) First how could I be running both PostGIS 2.2 and PostGIS 1.5 in the same
> session when you can't install both in the same db unless you do something
> crazy.

Uhm ? I thought this was exactly what you complained about ?
Oh, it was 2.1 and 2.2 ! Well, things don't change:
as both do include liblwgeom in them, and both do export its symbols,
any runtime resolver would not be able to decide which version of
any liblwgeom function to use.

Note this is only a problem for runtime lookups.
For example, shall GDAL dynamically links to liblwgeom
(which might, if I'm not mistaken).

> 2) Yes it's a bug these functions were ever exported out and I don't see how
> if there is a readily available version in the loaded library why postgres
> would choose to pull the same function from another library that has no link
> the main one.

It seems that once loaded, symbols are all in the same bucket, so the
linker can't tell which symbol comes from which library. Versioning
the symbols themselves would be one possibility to syntetize that
namespacing (GNU linker does support this).

> The ticket issue you have I thought was caused because you have a mix of
> dynamic lining and static linking.  Which both Paul and I were vehemently
> against.

I actually think the same should also happen with an all-dynamic
setup, unless symbols are versioned (i'd like to hear from Sebastiaan
about this).

> Anyway point remains the same I don't want my PostGIS 2.whatever1 sharing
> liblwgeom with PostGIS 2.whatever2.  They each should have their own
> statically linked private versions.
> 
> If it's broken for PostGIS 1.5, that's fine.  That's pretty dead to me.

So do you think we should backporting the "do-not-export-symbols" from
2.2 to 2.1 and 2.0 ? The only reason to export those symbols would be
for modules to be able to intentionally use the those functions from
the PostgreSQL module w/out re-linking to the library.

--strk;