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

[Greg Troxel]

Sandro Santilli <strk at kbt.io> writes:

> 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.

The current pkgsrc build results in:

$ ls /usr/pkg/lib/liblwgeom*
lrwxr-xr-x  1 root  wheel      22 Nov 19 19:41 /usr/pkg/lib/liblwgeom-2.5.so.0 -> liblwgeom-2.5.so.0.0.0
-rwxr-xr-x  1 root  wheel  584099 Nov 19 19:41 /usr/pkg/lib/liblwgeom-2.5.so.0.0.0
-rw-r--r--  1 root  wheel  958502 Nov 19 19:41 /usr/pkg/lib/liblwgeom.a
-rwxr-xr-x  1 root  wheel    1033 Nov 19 19:41 /usr/pkg/lib/liblwgeom.la
lrwxr-xr-x  1 root  wheel      22 Nov 19 19:41 /usr/pkg/lib/liblwgeom.so -> liblwgeom-2.5.so.0.0.0

I certainly see the 2.4 in the name of the actual .so, but I also see a
.a and a .la without the 2.5, and a symlink so without it.

Is my build/install broken?

> Not the PostgreSQL part though but that's irrelevant (liblwgeom
> does not depend on PostgreSQL).

True, but it does mean that multiple installations conflict, and I keep
hearing people talk about supporting that, even though it obviously
won't work (unless one starts to grab bits and pieces, and has one
actual installation and then perhaps the module only for others).

> 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.

Interesting point - I had not thought of that specifically.