[postgis-devel] PSC Vote: Stop installing liblwgeom INCLUDES in system

[Greg Troxel]

Paul Ramsey <pramsey at cleverelephant.ca> writes:

>> On Nov 28, 2018, at 9:36 AM, Greg Troxel <gdt at lexort.com> wrote:
>> 
>> 
>> "Regina Obe" <lr at pcorp.us <mailto:lr at pcorp.us>> writes:
>> 
>>>> If it's used semantically like a library -- which it really seems to be
>>>> -- you should allow dynamic linking within the build.  You are kludging
>>> around
>>>> lack of a design for managing multiple versions, and adding more
>>>> maintenance headaches.  So -1 from me, which I realize doesn't really
>>> count.
>>>> 
>>> [Regina Obe] 
>>> Not sure what you mean by used like a library.  
>>> The original reason why we had it segmented was because it was easier to
>>> test that way via CUNIT.
>>> Then later this segmentation proved a little useful when we introduced
>>> raster.
>>> 
>>> To me it's more a header only library that can be detached from Postgres for
>>> ease of testing.
>>> 
>>> To me it's just a pile of shared code across the different extensions
>>> postgis/ postgis sfcgal / postgis raster / postgis topology
>> 
>> That's the definition of a library :-)
>
> It’s a library that ONLY WE USE. And that we DO NOT want anyone else
> to use. We broke out the code for our purposes, it lets us do things
> like c-level debugging without firing up a backend, and valgrinding
> without fighting the postgresql memory manager. The point was never to
> share with others. Using the word “library” seems to make people want
> to install it in system locations (to the extent that the Debian
> packagers stripped away our default of statically linking it to the
> postgis.so module) and invite others in to play, and we do NOT want
> that. Is there a different word we can use?

I don't think the word is the big deal.  I don't think it matters if the
.so is installed; only about seeing linking as difficult if it is not.

I also don't think installing it in someplace other than ${PREFIX}/lib
is a problem, as if it's off in some subdirectory then it's more clear
that it's private.

It is that the combination of

  creating what the compiler/linker think of as a library for lwgeom

  building objects to go into a postgis.so

  some notion of static linking the bits from the lwgeom library into
  postgis.so

feels very fraught with trouble.  There are lots of systems out there,
multiple compilers and surely multiple linkers.  When building
libraries, source files are often compiled once in a way that works for
.a libraries (where the linker can do relocations at link time) and once
in a way that works for .so libraries.

So the operation

  take these .lo (PIC) files that are going to belong in postgis.so

  somehow merge in stuff from lwgeom.a/lwgeom.so

  produce a postgis.so

  while doing this, let postgis.so continue to DT_NEEDED on thinks like
  libgeos.so, meeting the usual security update concerns about having
  code inclusion

  expect this process to entirely work on all systems/compilers/linkers

is one that I don't really see how to do, other than by building the
lwgeom files as part of building postgis and treating them like objects
that need to be in the .so, just like the rest.  Basically making lwgeom
no longer a library in the sources.

Of course one could write a linker that deconstructs a .so and puts the
included objects in another so.  Maybe this is even supported already,
and maybe maybe universally on all systems that support shared
libraries.  But it seems new and different to me.

Other approaches are surely possible, but I think it's very tricky
business and needs a written design that explains why all the trouble
I'm worried about above cannot happen, on any system where postgis would
build now.