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

[Daniel Reed]

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 libexample.so to be re-pointed to libexample.so.0 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/libexample.la and 
/usr/lib/libexample.so to both be created, each pointing to 
libexample.so.1 . 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/libexample.so to 
be overwritten, not /usr/lib/libexample.la, 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 
libexample.so.0 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 libexample.so.0 .

Executables built by Libtool will resolve -lexample based on 
libexample.la, incorrectly matching libexample 0's header files to 
libexample.so.1 . 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 libexample.so, 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>      http://naim-users.org/nmlorg/   
http://naim.n.ml.org/
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools. -- Douglas Adams, Novelist