Re: libtool-2.0 release

[Gary V. Vaughan]

Ralf Wildenhues wrote:
> Hi Gary,

Hallo Ralf!

[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.]

> > > >  * <!> LT_WITH_LTDL should build libltdl by default; currently
> > > >        nothing happens unless LTDL_CONVENIENCE or LTDL_INSTALLABLE
> > > >        is also given.
> > >
> > > I don't even know what this means.  I'd guess we should ignore it?
> >
> > 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?  AFAIK the 1.5 docs require you to use
> AC_LIB_LTDL, _not_ AC_WITH_LTDL (that exists but isn't even mentioned in
> the docs), and AFAICS AC_LIB_LTDL *will* cause libltdl to be built: see
> the second old-am-iface.at test, which explicitly does this.  The
> updated form of AC_LIB_LTDL is LTDL_INIT, not LT_WITH_LTDL.  However,
> our current CVS HEAD documentation fails to even mention LTDL_INIT.  I
> wonder whether this is maybe a bug in documentation only?

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.  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.
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.

> > > >  * <!> fix potential denial of service with compilers that do not
> > > >        understand "-c -o".
> > >
> > > I don't mind postponing that to after 2.0, iff that is _not_ responsible
> > > for bugs like this one: http://bugs.debian.org/350989
> 
> > Okay.  I'll leave it on the list as is until you determine whether to
> > postpone or not.
> 
> The Debian bug is unrelated.  I'll still try to finish my pending patch
> today and post it: we can still decide then whether it's more risky to
> apply it or to postpone it.

Excellent!

>>>   IMHO (most notably the OpenBSD failure; and good would be the
>>>   application of the `-static-libtool-libs' patch for users that
>>>   need the other `-static' semantics; together with the hardlinking
>>>   regression that I also found for `-static')
>> I agree that fixing regressions is necessary.  I'm not sure that we
>> need to delay the release for new features...  Can you amend the RoadMap
>> to reflect your thinking on this please?
> 
> Sure.  Can we agree on adding `-static-libtool-libs'?  Rationale: the
> semantic change of `-static' effectively caused a regression for users.
> The new flag is to amend this.

Okay, if you think it will save bug-libtool traffic later.  Let me review
that patch in its own thread first.

> I'll await answer on this and update the TODO list then.

Cool, thanks!

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

> There was one other one, and from memory, I believe it goes like this:
> suppose we have a package with libltdl.  If the user does
>   --without-included-ltdl
> then I believe `-Ilibltdl' and such paths get still added to includes,
> which is wrong.
> 
> I don't remember from memory whether that was for subpackage libltdl,
> or for nonrecursive, or for recursive.  Sorry.

Ick.  I guess we'll trip over it during pre-release testing.

> 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 :-)

> We should probably work a bit on feedback documentation.  The rate of
> users for which the first reply is "please post this and that as well"
> is still a bit high.  I must admit being not too good at working on
> documentation

NP.  I'll take that one.

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).

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature