[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