[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool-2.0 release
From: |
Ralf Wildenhues |
Subject: |
Re: libtool-2.0 release |
Date: |
Fri, 3 Feb 2006 14:35:57 +0100 |
User-agent: |
Mutt/1.5.11 |
Hi Gary,
* Gary V. Vaughan wrote on Fri, Feb 03, 2006 at 01:06:40PM CET:
> Ralf Wildenhues wrote:
> >
> > However, I have absolutely no problem with delaying the application of
> > the per-deplibs-flags patch to shortly after 2.0.0 or 2.0.2. Although
> > we should still commit both the `-static' hardcoding fix and the
> > static.at test patch (the latter is written so that it works also
> > without the per-deplibs-flags patch; it needs only -static-libtool-libs).
>
> Agreed. The more tests we commit, the better. I think adding tests that
> will fail due to known bugs in the release is okay too... we just mark
> them XFAIL until the known bug is fixed after the release.
Sure.
> >> * <!> libtool.m4 macro ordering/requirement audit. pending
> >
> > This is as good as done.
> Okay, moved to 'fixed'.
Thanks!
> >> * <!> 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?
Disclaimer: I haven't tested anything now.
> >> * <!> 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.
> > 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.
I'll await answer on this and update the TODO list then.
> > - 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.
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.
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.
> > - AC_PROG_SED may not be AC_DEFUNed (for aclocal < 1.6?), and
> > LT_AC_PROG_SED should be catered for.
>
> D'oh! I have a patch for this already :-/ I'll post it presently.
Good.
> > - Makefile.am rules somewhere use GNU make 3.80 features. I have
> > encountered many difficulties preventing autotools reruns on other
> > systems, and am quite fed up with hunting these down.
>
> :-( I haven't tripped over those yet.
Well, to tell you the truth, I don't actually _know_ what the problem
is. I'd have posted or fixed it already then.
> > - I have a pending Solaris/whole_archive_flag_spec patch, fixing a
> > regression, and to make libtool work on Solaris 10.
>
> Cool! Please add an entry to the RoadMap.
I hope to post the actual patch today. I also expect it to pass review
quickly. ;-)
> > You webpage does not seem accessible at the moment.
>
> Yeah, my ISP seems to give me 10 min outages once or twice a week... or else
> my new modem takes that long to notice the dropped connection from the
> ISP end and redial. Sorry about that :-(
No problem. I must've just been lucky to hit that.
> > And I have several more tests which I would like to write or have
> > already started. For example: I would like comprehensive exposure of -L
> > path issues in order to fix the OpenBSD link `-L path order issue' right,
> > so that it does not turn into another regression on another system.
>
> Okay. Adding tests at any time is fine by me.
Cool.
> > I know you would rather release. There is a trade off: better test
> > exposure vs. release delay. My being fed up with working on bootstrap
> > and similar issues that were mostly introduced by the great code
> > reorganizations, and also there being very few test suite contributors
> > and people working on bug reports, has led me to work on the former.
>
> NP. However, there is plenty to be said for letting the community
> tackle some of the testing. Although we need to show diligence and not
> release with gaping bugs, a mostly good 2.0.0 release will provoke a
> huge amount of feedback and testing that we can funnel into a speedy
> 2.0.2. I'd hate for you to burn yourself out looking for corner cases,
> especially when much of that work will be done by the community post-
> release anyway.
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
> > Libtool will only get consistently better with a testsuite that exposes
> > much more issues. And if you then keep to adding features only with
> > comprehensive test exposure already (which static.at probably isn't for
> > the patch at stake here), then adding features to libtool won't
> > destabilize it much.
>
> ACK. I think we can be justifiably proud of the huge improvements we've
> brought to the new testsuite in the last 18 months.
:) I think with about 10-20 times as much test exposure we can have
almost well-defined semantics in libtool.
Cheers,
Ralf
- Re: per-deplib static/dynamic flags, (continued)
- Re: per-deplib static/dynamic flags, Bob Friesenhahn, 2006/02/01
- Re: per-deplib static/dynamic flags, Ralf Wildenhues, 2006/02/02
- Re: per-deplib static/dynamic flags, Bob Friesenhahn, 2006/02/02
- Re: per-deplib static/dynamic flags, Peter O'Gorman, 2006/02/02
- Re: per-deplib static/dynamic flags, Ralf Wildenhues, 2006/02/03
Re: per-deplib static/dynamic flags, Ralf Wildenhues, 2006/02/02
- libtool-2.0 release [WAS per-deplib static/dynamic flags], Gary V. Vaughan, 2006/02/02
- Re: libtool-2.0 release [WAS per-deplib static/dynamic flags], Bob Friesenhahn, 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 <=
- 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, Bob Friesenhahn, 2006/02/03
Re: libtool-2.0 release, Ralf Wildenhues, 2006/02/10