[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daniel Reed
Subject: Re: totally confused by versioning system of libtool...
Date: Fri, 13 May 2005 13:41:24 -0400 (EDT)

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
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:,, and . The latter two may be symlinks to the former.

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

If you then install libexample 0.0.6, it may install and change the symlinks to point to that, leaving on the disk. However, only the files and are ever directly accessed; programs that were linked with -lexample when pointed to only know that "" is what they want, they don't necessarily care what specific version of the file is installed. So, changing /usr/lib/ to point to instantly makes it so any program linked against will use 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; 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

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 and but not, because only the versioned files are needed for runtime; is only needed to link new programs. A package called "libexample-devel" might include the symlink and header files.

You could end up with something like:
    /usr/lib/ ->

    /usr/lib/ ->

    /usr/lib/ ->

Then upgrading libexample-0.0.5 to libexample-0.0.6 would never cause discrepencies, because it only would touch and, never 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,,, 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>
"Real computer scientists like having a computer on their desk, else
how could they read their mail?"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]