[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool-2.0 release
From: |
Gary V. Vaughan |
Subject: |
Re: libtool-2.0 release |
Date: |
Fri, 03 Feb 2006 14:43:11 +0000 |
User-agent: |
Thunderbird 1.5 (X11/20051201) |
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
- Re: per-deplib static/dynamic flags, (continued)
Re: per-deplib static/dynamic flags, Ralf Wildenhues, 2006/02/02
Re: libtool-2.0 release, Ralf Wildenhues, 2006/02/02
Re: libtool-2.0 release, Gary V. Vaughan, 2006/02/03
Re: libtool-2.0 release, Ralf Wildenhues, 2006/02/03
Re: libtool-2.0 release,
Gary V. Vaughan <=
Re: libtool-2.0 release, Ralf Wildenhues, 2006/02/03
Re: libtool-2.0 release, Bob Friesenhahn, 2006/02/03
Re: libtool-2.0 release, Ralf Wildenhues, 2006/02/10
Re: per-deplib static/dynamic flags, Gary V. Vaughan, 2006/02/02