[Top][All Lists]

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

Re: Libtool 2.2 ABI issue

From: Yoann Vandoorselaere
Subject: Re: Libtool 2.2 ABI issue
Date: Fri, 14 Nov 2008 11:51:23 +0100

Hi Ralf,

Le mercredi 12 novembre 2008 à 21:19 +0100, Ralf Wildenhues a écrit :
> * Yoann Vandoorselaere wrote on Wed, Nov 12, 2008 at 10:13:33AM CET:
> > Le mardi 11 novembre 2008 à 21:04 +0100, Ralf Wildenhues a écrit : 
> > > * Yoann Vandoorselaere wrote on Tue, Nov 04, 2008 at 04:16:47PM CET:
> > > > A fixe for this issue would be to be able to determine the libtool
> > > > version being used at compile time.
> > > You have a package you control (prelude) plus a number of packages that
> > > you don't control, but that use your headers/build plugins with prelude.
> > > 
> > > You control the libtool and libltdl versions with which prelude is built
> > > and installed (both from the Libtool 2.2.x tree), but you do not control
> > > the libtool version with which your "client packages" are built.  These
> > > client packages typically do not have anything to do with libltdl.
> > > 
> > > You do not need to be able to build prelude itself with Libtool 1.5.x
> > > any more (neither libtool nor libltdl).
> > That's mostly correct, but you need to keep into account that I have no
> > control on the version of libprelude installed on the system. Depending
> > on its version, libprelude will use 1.5 or 2.2 libltdl. 
> OK, so there are even more cases to consider:  :-/
> 1) libprelude could be built with Libtool 1.5.x or with 2.2.x.
> Is there at least consistency between the libtool version used to build
> libprelude and the libltdl version libprelude uses?

Libprelude shipped with libtool 1.5.x up to version, all
upcoming version will ship with libtool 2.2. 

The libltdl version included in the libprelude source is the one
imported from libtool, so that is libltdl 1.5.x if libtool 1.5.x is
used, or libltdl 2.2.x if libtool 2.2.x is used. 

Then if libltdl 1.5.x (rather than 2.2.x) is installed system wide, I'm
not sure whether libtool 2.2.x configure stuff will choose to use it or

> 2) However, IIUC then it is safe to assume that at least the version of
> libprelude itself is the newest.  Right?  I mean, you cannot put a
> workaround into an old version of your package without updating it.

That's correct, this mean all future libprelude version should have the
workaround enabled, to be bullet proof for existing application that
still rely on libtool 1.5.x

> I haven't thought about how to deal with (1).
> > If there is a mismatch between the libltdl version used to build
> > libprelude, and the libtool version used to build an application using
> > the libprelude plugin system, then the application will crash (unless we
> > install the workaround above).
> > 
> > Shouldn't the above workaround be done directly within libltdl?
> Maybe; not sure if it can be done solely inside libltdl though.

Are there other problem that this workaround doesn't address?

Yoann Vandoorselaere <address@hidden>

reply via email to

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