[Top][All Lists]

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

Re: Libtool 2.2 ABI issue

From: Ralf Wildenhues
Subject: Re: Libtool 2.2 ABI issue
Date: Wed, 12 Nov 2008 21:19:50 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

* 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?

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.

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.


reply via email to

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