Re: libtool-2.0 release

[Ralf Wildenhues]

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