Re: totally confused by versioning system of libtool...

[Daniel Reed]

On Fri, 13 May 2005, Ed Hartnett wrote:
> Daniel Reed <address@hidden> writes:
> > Many projects will continue to make bug fix releases even if a newer
> > API is currently under development--including Libtool itself. For this
> > example scenario, if libexample-1.0.2 is the current release, but a
> > critical bug is found in both it and libexample-0.0.5, then you can
> > feel free to release libexample-0.0.6 and libexample-1.0.3 at the same
> > time.
> So this is not actually replacing libexample-0.0.5, it is adding
> libexample-0.0.6, and the loader is smart enough to automatically use
> that in preference to libexample-0.0.5.

Sort of. Parallel install of runtime support files (such as runtime 
libraries) is accomplished by reducing the versioning information of the 
installed files to the point where all distinguishing characteristics 
related to binary compatibility are kept, but everything else is dropped.

When you install libexample-0.0.5, it may install three files in your lib 
dir: libexample.so.0.0.5, libexample.so.0, and libexample.so . The latter 
two may be symlinks to the former.

When you link a program using -lexample, it will look at libexample.so and 
see that its internal name is libexample.so.0, and so will store that name 
in the program. When the program starts up, it will ask the runtime loader 
to find libexample.so.0 for it, and it will find libexample.so.0 a symlink 
to libexample.so.0.0.5 and use it.

If you then install libexample 0.0.6, it may install libexample.so.0.0.6 
and change the symlinks to point to that, leaving libexample.so.0.0.5 on 
the disk. However, only the files libexample.so and libexample.so.0 are 
ever directly accessed; programs that were linked with -lexample when 
libexample.so pointed to libexample.so.0.0.5 only know that 
"libexample.so.0" is what they want, they don't necessarily care what 
specific version of the file is installed. So, changing 
/usr/lib/libexample.so.0 to point to libexample.so.0.0.6 instantly makes 
it so any program linked against libexample.so.0 will use 
libexample.so.0.0.6. libexample.so.0.0.5 will therefore no longer be used, 
for any purpose. In that way, libexample 0.0.6 is replacing libexample 
0.0.5.


> Is that correct? And libexample-0.0.5 stays on the users' systems
> until they feel like deleting it, but it is ignored by the loader
> because a fresher version exists.

Yes; libexample.so.0.0.5 may remain on the disk, but it will never be 
used, even by software that was originally linked against it.


> But I don't understand why it's not 0.5.0 and 0.6.0. That is, wouldn't
> it be a case of incrementing the minor version number, the middle
> number?

If libexample 0.0.6 is merely a bug fix, it is usually customary to only 
updated the least significant number in the version string. Customarily, 
however, only the very first number is ever used for runtime linking (so 
libexample 0.0.0, libexample 0.0.1, and libexample 0.1.0 would all replace 
each other, but libexample 0.1.0 and libexample 1.0.0 could be installed 
in parallel).


> > would not necessarily cause explosions, just different-than-expected
> > but still functional behavior). The next time the libexample 1 series
> > was upgraded everything would go back to normal.
> But if we were updating two versions of our software at once, we
> could do it in the correct order, so that libexample 1 is done after
> libexample 0. Is that correct?

If you have control over the practices of everyone who will be using your 
library, then yes, you can guarantee it will be done in the 
least-confusing order.


In general, however, you don't have such control, which is why many 
operating system distributors use a convention of keeping the runtime 
support files separated from the compile-time or "development" files. A 
package called "libexample" might include libexample.so.0.0.5 and 
libexample.so.0 but not libexample.so, because only the versioned files 
are needed for runtime; libexample.so is only needed to link new programs. 
A package called "libexample-devel" might include the symlink 
libexample.so and header files.

You could end up with something like:
  libexample-0.0.5:
    /usr/lib/libexample.so.0.0.5
    /usr/lib/libexample.so.0 -> libexample.so.0.0.5

  libexample-1.0.2:
    /usr/lib/libexample.so.1.0.2
    /usr/lib/libexample.so.1 -> libexample.so.1.0.2

  libexample-devel-1.0.2:
    /usr/lib/libexample.so -> libexample.so.1
    /usr/include/example.h

Then upgrading libexample-0.0.5 to libexample-0.0.6 would never cause 
discrepencies, because it only would touch libexample.so.0.0.x and 
libexample.so.0, never libexample.so nor the header files. When libexample 
1.0.3 was installed, it would cause libexample-devel 1.0.3 to be installed 
too, updating all of libexample.so.1.0.x, libexample.so.1, libexample.so, 
and example.h. Any number of base packages could be installed, but only 
one development package would be allowed.

But this is not a function of Libtool.

--
Daniel Reed <address@hidden>      http://naim-users.org/nmlorg/   
http://naim.n.ml.org/
"Real computer scientists like having a computer on their desk, else
how could they read their mail?"