[geos-devel] Re: Versioning scheme, binary compatibilities and future of GEOS

[strk at refractions.net]

On Mon, Dec 19, 2005 at 05:07:29PM +0100, Eric Faurot wrote:
> On 12/19/05, strk at refractions.net <strk at refractions.net> wrote:
> 
> > Plese send postgis patch quickly as release date for 1.1.0
> > is set to this wednesday (might be delayed for this need).
> 
> These are actually not really important. The compiler does not
> like sprintf and strcpy but that's ok. The biggest trouble is
> that regress fails (#62/#63) because infinity is stringified as "Inf"
> instead of "inf". Using diff -i in run_regress does the trick. There
> is also a failure on macppc (for OGC regression test), due to
> slight differences in floats representation. Maybe checking (in SQL)
> that the distance to the expected result is small enough would
> be better than comparing the output in this case.

Could you try with current CVS snapshot ?
We should have handled those cases by using sed 'to' normalize
Inf and e[+-]xx representations.

> > Using major numbers would allow keeping some form of compatibility,
> > but the whole point is reducing cost of traking this, which is
> > feeling free to break ABI for the sake of speeding up the operations.
> >
> > Always increasing Major would just be aestetically unpleasant, and
> > would also make it harder to find out which release does a library
> > come out from.
> 
> Well, I have libc.so.38.4 and libstdc++.so.40.0 and I don't find that
> too disturbing :). Better than libpangoft2-1.0.so.1001.1 anyway. Also,
> I suspect some day the ABI will stabilize enough to be kept compabible
> between two minor releases, having it bound to a release name will
> be a pain then.

The only way I can see ABI to stabilize is drastically reducing it.
In that case having another name for the library won't be such
a pain... it could be libgeos++.so.1.0.0 - for example.

> > > About the C API, well, I don't find the libtool versioning framework
> > > very interesting and practical.  Note that BSD linker only knows about
> > > the major and minor numbers. A program can link to a library if it has
> > > the same major number and a minor number smaller or equal than the
> > > library. Three-number schemes do not fit.
> >
> > Yeah, I noticed that. On *BSD systems GEOS-2.1.0 produced libgeos.so.3
> > and GEOS-2.2.0 produced libgeos.so.4, preventing automatic use
> > of the Minor releases from already built executables.
> 
> I cannot speak for the others, but on OpenBSD, it builds libgeos.so.4.1
> and libgeos_c.so.1.1 with GEOS 2.2.1, which looks coherent with the
> provided INTERFACE_CURRENT and INTERFACE_REVISION. Also, there
> is no symlink trick used to make libfoo.so resolve as libfoo.so.3 resolve
> as libfoo.so.3.6.

Mmm.. doesn't sound coherent to me.

C++ curr:1 age:0 rev:1 should bring to libgeos_c.so.1.0.1
C   curr:4 age:2 rev:1 should bring to libgeos.so.2.2.1

On FreeBSD 4.2 minor is completely unused and the above results in
	libgeos_c.so.1 (symlink libgeos_c.so)
	libgeos.so.4 (symlink libgeos.so)

To summarize up:

	Linux uses CURR and AGE for major, AGE for minor, REV for micro
	OpenBSD uses CURR for major, REV for minor (AGE unused)
	FreeBSD uses CURR for major (REV and AGE unused)

> > At a first glance I supposed this was due to possibly limited *BSD
> > capabilities (something about symbol relocation?). Do you know, as
> > an OpenBSD user why does libtool acts like that ?
> 
> I think the policy was to keep things very simple: bump the minor number
> for incremental ABI/API changes, and bump the major number for
> disruptive changes.  The problem is that lots of programmer started
> to use libtool without carrying much about library numbering, happily
> mixing project version, releases and library names. So some things
> are now pretty messy (gtk2 for example).

Actually, libtool info page is pretty clear about numbering.
It is supposed to take care itself of different dynamic linkage
implementations. I'd *not* give up libtool usage for GEOS.
Rather, I think we should understand whether we're doin something
wrong with release procedures.
For example some time ago we had to upgrade libtool on the machine
on which releases were packaged. Somebody suggested that running
libtoolize would have forced it somehow, but I'm still confused
about what is done when and where.

--strk;