Re: libtool-2.0 release

[Ralf Wildenhues]

* Gary V. Vaughan wrote on Fri, Feb 03, 2006 at 03:43:11PM CET:
> 
> [Is the personal Cc: okay?  The list lag is so long that I've gotten into
>  the habit of Cc:ing you back in so you don't have to wait half a day to
>  get this.]

Yes, surely.  There was one point in time where I fixed my gnu.org
subscriptions to do what I want for my mail setup, and since then I
could stop bothering about this for mails sent to me.

List lag is interesting though: it can vary between several hours and
less than a minute within the time frame of 12 hours.  I am at a loss
how to explain this, maybe it's fast when the US-based spammers go to
sleep. ;->

> > > It means that LT_WITH_LTDL in configure.ac that mentions neither
> > > LTDL_CONVENIENCE nor LTDL_INSTALLABLE doesn't build libltdl at all.
> > > I have a start to a fix for this.
> > 
> > Well, so is that really a bug?

> I originally wrote LT_WITH_LTDL as a convenience wrapper for AC_LIB_LTDL
> in CVS M4, and realised that it was useful enough to almost all clients
> of libltdl that it should probably belong in the Libtool distribution...
> There is definitely a documentation bug (added to RoadMap) that it is
> still undocumented.

It's not LT_WITH_LTDL that is undocumented.  LTDL_INIT is.

> The real question then is whether LT_WITH_LTDL alone
> should be equivalent to LTDL_CONVENIENCE plus LTDL_INIT (overridable
> with LTDL_INSTALLABLE) or whether it should be *in addition* to all that.

Right.

> I'm leaning toward the former, but either way the current situation of
> being like LTDL_INIT plus --with-ltdl processing is counter-intuitive.
> I'll post a documentation patch to help us define the semantics clearly,
> and then fix the code to implement what we decide upon.

Good.

> >>> - I know about a couple more tweaks necessary for HEAD libtoolize
> >>>   and Bob has a couple of failures I (or somebody else) need to track
> >>>   down.
> >> Agreed.  If you put them on the RoadMap, I might get to them before you.
> > 
> > Well, this comment of Bob completely mystifies me:
> > http://article.gmane.org/gmane.comp.gnu.libtool.patches/6582
> > I believe in that thread there were more issues mentioned.
> 
> Can you transcribe them to the RoadMap once we've got clarification on
> the issue from Bob please?

OK.  I'll ask him to test again after patch-6 is in (or test myself).

> > Ahh, and there was another one: the breakage on need_lib_prefix systems.
> > I think we did not mark it release-blocking, but I still would like to
> > test Pierre's patch extensively and use it if it turns out good:
> > otherwise libltdl will be completely useless on e.g. BeOS.
> 
> Okay.  Is that a long standing bug, or a regression?  Please mark the
> RoadMap accordingly :-)

Well, both.  Apparently dlpreloading has never worked on need_lib_prefix
systems, so that is long-standing.  Now that libltdl requires working
dlpreloading, it fails to work completely, while in 1.5.x it at least
worked in some cases.  From a user POV, that's a regression, from a
Libtool developer POV it's long-standing.  ;-)

> Just discovered yet another in my patch queue (needs another round of
> testing before I post): make installcheck currently always fails in
> trees that used 'libtoolize --ltdl' in some modes. (Added to RoadMap).

OK.

Cheers,
Ralf