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

[Sandro Santilli]

On Wed, Nov 28, 2018 at 10:19:53AM -0500, Greg Troxel wrote:

> A good design would ensure that all things installed are versioned, both
> by pgsql version and by postgis version.  That includes command-line
> tools and headers as well as libraries.  So that means not putting
> liblwgeom in ${PREFIX}/lib at all, or calling it
> liblwgeom-pgsql95-postgis25 (before the shlib version!).  It seems best
> to put it in a named directory.

If I recall correctly we started encoding PostGIS version in the
liblwgeom filename, something like: liblwgeom-3.0.so.0.0.0
That is, *before* shlib version we do encode the postgis part.
Not the PostgreSQL part though but that's irrelevant (liblwgeom
does not depend on PostgreSQL).

We did this renaming of liblwgeom on October 2015, revision 14171,
which ended up first in PostGIS-2.2.0.

The problem of multiple libraries at runtime is actually showing up
more when liblwgeom is linked _statically_ instead of dynamically,
because a PostgreSQL process loading multiple PostGIS libraries
(postgis, rtpostgis or postgis_topology) may end up having multiple
_different_ versions of the same liblwgeom symbols.

Linking _dymamically_ to the library would actually _reduce_ that
problem, and I'm happy with going in that direction.

That said, avoiding to install the header file I've no problems with.

--strk;