[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 12:07:02 -0400 (EDT)

On Fri, 13 May 2005, Daniel Reed wrote:
People using software that depends on libexample's 1 series should not be confused by the new release for the older 0 series, because 0.0.6 is still less than 1.0.anything. The only down side is that installing libexample 0.0.6 might cause to be re-pointed to and libexample 0's headers to overwrite libexample 1's headers, so software that is compiled after an upgrade might be forced to use the libexample 0 API and ABI instead of libexample 1's (which would not necessarily cause explosions,

And a potential scenario where the symlink/la mismatch can occur, causing explosions: If the 0 series did not use Libtool, and hence never installed an la file, but the 1 series does use Libtool, and hence installs an la file.

Installing libexample 1.0.2 will cause /usr/lib/ and /usr/lib/ to both be created, each pointing to . It will install its header files, defining structs and function prototypes, into /usr/include .

Then installing libexample 0.0.6 will cause only /usr/lib/ to be overwritten, not /usr/lib/, because libexample's 0 series did not use Libtool. libexample 0.0.6 will also install its header files over libexample 1.0.2's--which is correct as long as the linker will use when linking with -lexample, because your program would need libexample 0's prototypes and structs to properly link.

Executables that are built by hand or otherwise not using Libtool will have -lexample passed to the linker, which will resolve based on the symlink, correctly matching libexample 0's header files to .

Executables built by Libtool will resolve -lexample based on, incorrectly matching libexample 0's header files to . This can cause a compile-time failure if the API changed in certain ways (such as the removal of a function that the program believe existed due to a #define), but may cause mysterious run-time failures more often (such as if a function changed from accepting an int to accepting a float, or if a new element was added to a struct shared by the library and the program).

just different-than-expected but still functional behavior). The next time the libexample 1 series was upgraded everything would go back to normal.

This is still true regardless, though. The moral is, if you do release an update to an older branch, make sure care is given that either it both won't overwrite already-installed headers nor update, or will update/remove an installed .la file it wouldn't normally replace. That is, it either has to repoint all potential compile/link-time references to itself, or it has to repoint none of them. The simplest way to do that might be to go back and convert older trees to use Libtool just for a bugfix release.

Daniel Reed <address@hidden>
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools. -- Douglas Adams, Novelist

reply via email to

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