[Mesa3d-dev] Re: libtool (was CVS and SSE)

[Sven M. H. <pe...@gm...>]

On Mon, May 21, 2001 at 10:19:40AM -0600, Brian Paul wrote:
> > Satisfying both libtool and the Linux ABI, I suggest this:
> > 
> > - Set a libtool -version-info of 0:MESA_VERSION:0 where MESA_VERSION would be
> >   30500 for Mesa 3.5.0.
> > - Follow the rules for libtool version info in updating the CURRENT and AGE
> >   fields.
> > - On Linux (for ABI-conformance), use an install-hook to create two symbolic
> >   links: libGL.so.1 to libGL.so.0.MESA_VERSION.0 and libGL.so to libGL.so.1.
> > - Follow the same rules for GLU and GLUT.
> 
> 
> I've been using the libGL.so.1.2.0x0y0z convention for a while now and
> people seem to like it.  I really don't want to change the convention
> yet again.
> 
> I realize that libtool tries to formalize the version numbers assigned to
> a library and that's fine.  But sometimes a library has to be numbered
> according to long-established conventions that don't match libtool's
> method.

Those long-established conventions are reflected in the ABI. That's why I
suggested to create a symlink for the name libGL.so.1. However, that name (as
I overlooked) conflicts directly with the libtool scheme. See all the way
below for a solution.


> IMHO, libtool should have an option to support arbitrary version numbers.

No it shouldn't. See below.


> Anyway, we seemed to have made libtools accept the 1.2.0x0y0z convention
> in recent versions.  Why can't we continue with that?

The point is that what libtool places there where you want to put a version
number is not a version number at all. It's a certain code describing the
interfaces a library exports. That's also the reason why libtool performs that
check: Using traditional version numbers would result in interface information
that doesn't make sense. This could lead the dynamic linker to not linking a
program because the library it finds doesn't appear suitable, although it is.


I have just played around with libtool a bit because I was curious how it
would actually go about enforcing the run-time checking of the interfaces.
I found out that it actually uses (at least on Linux, that is) a _file_
_name_ scheme very (I'd like to say _exactly_) similar to the version
numbering scheme used by the OpenGL standard, which is (correct me if I'm
wrong) to reserve interface changes to major releases, keeping backwards
compatibility among all releases with the same major number.
 
Now what libtool does:
Out of the interface numbers CURRENT, REVISION and AGE (assuming you know
their meaning) it computes a version number of the form M.m.r
like this:
  M = CURRENT-AGE
  m = AGE
  r = REVISION
The name of the binary becomes:
  libX.so.M.m.r
Two symbolic links to it are created:
  libX.so
  libX.so.M
The resemblence to what we're used to is astonishing! However, the final part
is the one that is important, because it is the one that produces the run-time
interface checking semantics I was looking for:

Executables are linked using -soname=libX.so.M !

That naming convention, combined with the rules for the CURRENT, AGE, and
REVISION numbers from the libtool documentation have the effect that any
library which obsoletes some interface ("increment CURRENT, reset AGE") gets a
new major number while those that keep the old interfaces ("increment CURRENT
and AGE") retain the same M.

I don't know, maybe that discovery isn't new to you, but at least I couldn't
directly derive this from the libtool docs. :}


Anyways, knowing how libtool naming works and that OpenGL versioning is
compatible with it we can probably safely reverse the whole thing and
calculate libtool-style CURRENT and AGE from OpenGL M and m. :)

With M=1, m=2: CURRENT=3, AGE=2. Finally we can set REVISION to the Mesa
version number. Libtool doesn't allow leading zeroes, though; it wants nice
and plain integers. I say we just compute a nice and plain integer for it:

With Mesa major, minor and release numbers being MM, Mm, and Mr respectively:
  r = MM * 10^4 + Mm * 10^2 + Mr
I know this will effectively drop the leading zero, but I think we could
accept that compromise.

So there:
libGL.so.1.2.30500
libGL.so.1 -> libGL.so.1.2.30500
libGL.so -> libGL.so.1


My fingers hurt.
-Sven

-- 
"Would the All-Seeing Eye please look in my direction?"
 [ KeyID........: 0xC297FEAB ]
 [ Fingerprint..: FEA5 0F93 7320 3F39 66A5  AED3 073F 2D5F C297 FEAB ]