Re: Migrating existing libraries to libtool

[Robert Boehne]

Keith,

Tough problem you've got here, I don't really see a way
around it without a new versioning flag other than
creating a libX??.la file for the last version of a library
you're attempting to install (which may or may not work anyway).
I would say that a patch to add this flag should warn the user
that this flag is only for situations like yours, where some
other versioning scheme must be supported for legacy reasons.
Documentation would also need to reflect this.  We wouldn't
want new users to abuse this flag because the don't understand
what Libtool is doing.
Send in the patch soon, and it could be in the 1.5 release.

Thanks,

Robert


Keith Packard wrote:
> 
> Around 2 o'clock on Feb 18, Simon Richter wrote:
> 
> > To remain binary compatible, it suffices to have the same major version,
> > as programs are expected to link against the .so.<major> file. Which
> > file this actually symlinks to is irrelevant. So in fact you start off
> > using -version-info <major>:0:0 and then go on as in the libtool
> > manual.
> 
> No, that will give minor version 0 which would be seen as *older* than the
> previous version of the library.  I really need major and minor versions
> to match so I can build replacement versions with the new tools that match
> precisely with what's already installed.
> 
> > Hrm, how is that solved currently with imake?
> 
> Imake has all of the necessary system-dependent mechanisms to generate
> correct link commands given the desired major and minor version numbers.
> It doesn't modify the version numbers provided, it simply uses whatever
> pieces are appropriate and ignores the low order values.  This has worked
> for some time now and developers have become comfortable with the
> kind of version checking and compatibility issues related to the set of
> platforms this is deployed on.
> 
> I've tried to use automake for existing X libraries and eventually had to
> give up and fall back to autoconf as libtool was unable to preserve the
> correct major and minor versions on even Linux and BSD.  I'd rather not be
> forced to support yet another krufty set of build kludges for X just
> because libtool has different ideas on library versioning schemes than
> we've been using for X.  automake is so close to working, let's close the
> gap and let imake die a well deserved death (with apologies to Todd
> Brunhoff)
> 
> -keith
> 
> _______________________________________________
> Libtool mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/libtool