[postgis-devel] For PostGIS 2.2 moving forward make liblwgeom compatible between micro releases

[Sebastiaan Couwenberg]

On 30-07-15 16:47, Paul Ramsey wrote:
> Only one ver number? We rev liblwgeom waaaaay more often than that.

Stabalizing the liblwgeom ABI impacting changes to not require dependent
projects to rebuild evertime a new PostGIS micro version is install is
the point of #2278.

>> On Jul 30, 2015, at 3:00 AM, Sandro Santilli <strk at keybit.net> wrote:
>>> On Tue, Jul 28, 2015 at 09:06:57PM +0200, Sebastiaan Couwenberg wrote:
>>> liblwgeom should move to a stable SONAME like liblwgeom.so.2 that only
>>> changes when the ABI breaks, e.g. using `libtool -version-info`.
>>>
>>> https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
>>
>> As of r13855 liblwgeom switched to properly versioned interface.
>> The SONAME for next library will be liblwgeom.so.2
>>
>> Tests are welcome.

I don't think linking the libtool version-info to the postgis version in
this way is correct. The changes in r13855 for PostGIS 2.18 result in
-version-info 3:1:8 which is an invalid value as documented in the
libtool manual:

"
 Also note that age must be less than or equal to the current interface
 number.
"

The single digit SOVERSION is the result of current - age. That's why
you need to increment them together when no ABI breaking changes have
been introduced as documented in the second example in the libtool manual:

"
 /Never/ try to set the interface numbers so that they correspond to the
 release number of your package. This is an abuse that only fosters
 misunderstanding of the purpose of library versions. Instead, use the
 -release flag (see Release numbers [1]), but be warned that every
 release of your package will not be binary compatible with any other
 release.

 The following explanation may help to understand the above rules a bit
 better: consider that there are three possible kinds of reactions from
 users of your library to changes in a shared library:

  1. Programs using the previous version may use the new version as
     drop-in replacement, and programs using the new version can also
     work with the previous one. In other words, no recompiling nor
     relinking is needed. In this case, bump revision only, don’t touch
     current nor age.
  2. Programs using the previous version may use the new version as
     drop-in replacement, but programs using the new version may use
     APIs not present in the previous one. In other words, a program
     linking against the new version may fail with “unresolved symbols”
     if linking against the old version at runtime: set revision to 0,
     bump current and age.
  3. Programs may need to be changed, recompiled, and relinked in order
     to use the new version. Bump current, set revision and age to 0.

 In the above description, programs using the library in question may
 also be replaced by other libraries using it.
"

I sugges to start with -version-info 2:0:0 in PostGIS 2.2.0, and keep
the libtool versioning of liblwgeom separate from the PostGIS version.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1