[postgis-devel] liblwgeom symbols exported by postgis module

'Sandro Santilli' strk at keybit.net
Mon Sep 28 10:57:17 PDT 2015


On Mon, Sep 28, 2015 at 09:31:00AM -0400, Paragon Corporation wrote:
> Oh god no.  Please don't force  that on me.  I was accepting just
> having my executables screwed and now you want my postgresql lib files
> screwed as well?

Having the Debian packagers in this thread it may be a good idea
to ask for help about this screw-up you're talking about ?

So far I've been screwed by the static linking (due to symbol
re-exporting).

> Here is the thing.
> 
> I run PostGIS 2.1 and 2.2 on the same PostgreSQL  instance (heck I also run PostGIS 1.5 sometimes on same instance).  If we make changes to liblwgeom in a minor release, even if the api did not change, I don't want my older PostGIS  affected by it.  Because I use that for easier regression testing knowing that the only thing that changed is PostGIS is PostGIS (e.g. I'm fine they share the same geos etc. cause I'm not testing that and like all else being equal).

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

Did you ever run tests involving use of both postgis-1.5 and
postgis-2.0+ in the _same_ session ? Do we have anything like
that setup as an automated test ? As I suspect it's already broken,
also with static linking.

> So if you force such a thing, PLEASE MAKE SURE IT'S OPTIONAL so I can count myself out.

I've no rush to move there, just got to know that Debian is doing this
already in the packaged versions.

--strk; 



More information about the postgis-devel mailing list