[postgis-devel] Why do we still install liblwgeom includes

Regina Obe lr at pcorp.us
Tue Nov 27 15:57:09 PST 2018


It seems we have this discussion every 5 or 6 months.  I was going to put in
an FAQ or something so at least I don't have to repeat myself.
I haven't found the words to concisely say it without rambling.

> >
> > Using liblwgeom outside of PostGIS is not supported so qgis processing
> > plugin shouldn't be using it and if they are they are stuck on an old
> > version.
> > So any package using it is doing so at their own risk.
> 
> Which is a bit different than causing it to break, putting packagers in a
bind
> between
>   not updating postgis
>   disabling the other one
>   doing something kludgy
> 
> is there a bug open in the plugins' tracket to get them to not do this?
> 
[Regina Obe] 
I don't know.  It's possible since I think a while back they suffered a
breakage when PostGIS was upgraded.
I remember hearing people complain, though that's anectdotal.

> This seems more about installing multiple postgis versions at once.
[Regina Obe] 
And lots of people do that.  We support that.  Even at PostGIS 3.0, it's
quite possible 
Users will have multiple versions of PostgreSQL, one with possible 2.5 and
another with 3.0
In fact it's almost guaranteed to be the case for people upgrading via
pg_upgrade.

> It's very normal to link against libraries built within the source tree
and then
> after installed, with -L/-R, after including headers with the right -I
flags.
> 
> Presumably then you are talking about not installing the .h and also not
> installing the .so, instead somehow linking those bits into postgis.so.
[Regina Obe] 
Our current build setup statically links liblwgeom into postgis-*.so,
rtpostgis-*.so
But some packages -- pointing my finger strongly at Debian folks, don't like
this and hack their configure scripts to prevent this.

https://sources.debian.org/patches/postgis/2.5.1+dfsg-1/link-liblwgeom/
https://trac.osgeo.org/postgis/ticket/3290


However the commandline tools do dynamically link to liblwgeom which
On my side (on windows,), I'm guilty of hacking my script the other way to
statically link in the libwgeom into my shp2pgsq, raster2pgsql cause I hate
rogue liblwgeoms flying around and don't want to figure out which liblwgeom
my raster2pgsql or whatever is linking to.

Anyway I think at least these days we put the micro version (at least minor)
in the liblwgeom library file name so it's called something like
liblwgeom-2.5.2.so when installed 
Because  we ran into issues with people having broken installs because their
postgis (on debian) was linking to the wrong liblwgeom or missing or the one
it was linking to got uninstalled.  

 It's been a while since I've let liblwgeom be free on my system, so I don't
know if it has versioning on the file name - perhaps someone can confirm.


That said I think we are all in agreement that the include files should not
be installed because NO ONE distributing their software (not part of PostGIS
code base) should be using it for their projects.  Starting with 3.0 at very
least.  Some folks on PostGIS (discussed on IRC
http://irclogs.geoapt.com/postgis/%23postgis.2018-11-27.log ) - feel doing
this in lower versions is too breaking.

We'll put a big breaking change in 3.0 release notes when we remove the
include, for folks that are building against system installed.

Whether we install the dynamic liblwgeom - the jury is split on that.  Not
installing it would mean statically linking the commandline tools which
folks don't like, so I think we'll always have it created and installed.  I
still don't like the idea of it not being statically linked into postgis-.so
and rtpostgis-.so cause I feel that's just asking for trouble.

e.g. if you uninstall postgis-2.5 on your PostgreSQL 9.5 but keep it
installed on your PostgreSQL 10 -- if liblwgeom is installed in system and
both are sharing it, even if versioned with liblwgeom-2.5.whatever
and you want to have a clean uninstall, your living install may not be
happy.  I'm not sure how Debian deals with that.  I think for Debian core
it's a non-issue cause they don't really support more than one version of
PostgreSQL installed to my knowledge.  For apt.postgresql.org I can see it
being a possible issue.


> Beware that libtool is fussy about mixing .a/.so, so todo this sanely is
going to
> need folding the lwgeom source files into the postgis library, and
essentially
> merging them, so that lwgeom is no longer a thing.
> (That to me seems like more trouble than we have now.)
> 
[Regina Obe] 
Hmm - that's the way it is now - liblwgeom is statically linked into the
postgis.so unless you hacked the configure script like debian folks did to
have it dynamically linked.

> I don't think this is a big deal - just my $0.02, and if it's dropped,
anything that
> depends on it will almost certainly just get marked broken.
[Regina Obe] 
People have been advised to use librtopo.  I think Spatialite already
switched to that - and the Sandros (PostGIS Sandro, SpatiaLite Alesandro)
manage that project.

https://git.osgeo.org/gitea/rttopo/librttopo


Thanks,
Regina





More information about the postgis-devel mailing list