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

[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
> 
[Regina Obe] 
Two more reasons to prefer static linking for postgis extension libs and I
would say for the commandline tools as well.
As Darafei pointed out, if you compile postgis with SFCGAL support, your
liblwgeom depends on SFCGAL which means EVERYTHING depends on SFCGAL.

However we observed that with postgis/rtpostgis statically linked to
liblwgeom, the SFCGAL dependency in the .so is void of SFCGAL dependency.
In fact rtpostgis has no dependency on GEOS if statically linked which is in
the liblwgeom.so though GEOS is a dependency on the liblwgeom.so

I think that was the original reason I statically linked my
raster2pgsql/shp2pgsql because I noticed the liblwgeom.dll had an SFCGAL
dependency and I didn't want these executables which had NO REASON
whatsoever of needing SFCGAL being infected by this cause it made them much
less portable.

Darafei also mentioned that with libwlgeom dynamically linked we can't use
JIT in postgresql.  Maybe someone can confirm that.

Darafei asked why I prefer static linking liblwgeom and my reason I
mentioned is NOT just because I build for windows.

In the case of liblwgeom, there is always a version of liblwgeom with each
PostGIS, intended to be used JUST for that version of PostGIS.
So you aren't gaining any security benefits or performance improvements as
you would by having a dynamically linked GEOS / GDAL/ or SFCGAL.

You SHOULD always be compiling these together as a unit to prevent
unexpected behavior.

So reasoning of why packagers normally dynamically link "I want to be able
to apply a security update or performance enhancments without having to
recompile all packages that depend on X" , doesn't hold water here.


Thanks,
Regina