[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Who is going to fix libtool-1.5 bug in cvs?
From: |
Bruno Haible |
Subject: |
Re: Who is going to fix libtool-1.5 bug in cvs? |
Date: |
Wed, 21 May 2003 17:22:28 +0200 (CEST) |
Hi Robert,
I'm sorry to have to talk about the form of my bug report, but you
force me to do so.
> Complaints are not nearly as effective as sending a patch
> in the proper format.
I sent a patch, and in the proper format, with ChangeLog entry.
If you cannot or don't want to read patches in context diff format,
there is a utility that can convert it for you at
http://freshmeat.net/projects/diffconvert/?topic_id=849
(Put this converter "cd2ud" as a filter into your .procmailrc.)
> I've seen quite a few of these patches
> in context diff format and against some ancient version
The patch we are talking about was against libtool-1.5, 10 days after
libtool-1.5 was released. You cannot call this "some ancient version".
> and to the wrong list
I sent it to the libtool-patches list, because, as I understood,
- bug reports without patch should go to bug-XXX,
- bug reports with patch should go to XXX-patches.
> However, if the patch posting *clearly* shows that there is
> a problem in Libtool I will generally take the trouble to
> fix it. The patch you referr to has an explanation that
> doesn't seem to have anything to do with the patch. It goes
> on about aclocal.m4 being too large, having the wrong libtool.m4
> in certain cases, etc. but nothing to explain how AC_PROG_EGREP
> is the cause of any of it.
If my posting didn't convince you, you could have replied to me
"Please give more explanations", and I'd have given them.
In any case, I gave a "how to reproduce" and ensured that:
1. You can reproduce the bug with libtool-1.5 in a matter of a
minute.
2. After applying the patch I sent and rebuilding and reinstalling,
you cannot reproduce it any more.
> I don't find it very interesting or responsible to
> blindly apply patches that I don't understand or see a reason for.
I agree with you that it's not responsible to blindly apply patches
without reasoning.
Here's the explanation of the bug: 'aclocal', when it decides which
files to concatenate to form aclocal.m4, simply looks for the macros
used by the configure.ac file and for the macros defined by the
various *.m4 files. Now since AC_PROG_EGREP is an autoconf built-in,
it is usually not defined in *.m4 files. With one exception:
libtool.m4 from libtool-1.5 defines it. So 'aclocal' ends up including
both the libtool.m4 from libtool-1.4.3 into aclocal.m4 (because it
defines AC_PROG_LIBTOOL, required by configure.ac) and also libtool.m4
from libtool-1.5 (because it defines AC_PROG_EGREP, equired by
configure.ac). 'aclocal' doesn't know which are autoconf built-ins.
And the intent of the configure.ac author was to use the autoconf
built-in (because AC_PROG_EGREP is documented in the autoconf
documentation, not in the libtool documentation).
Should I also explain _why_ the patch works, or is sufficient for you
to convince yourself by applying and testing it?
> Best yet, submit a new testcase that your patch fixes.
Can you please tell what was wrong with the testcase in
http://mail.gnu.org/archive/html/libtool-patches/2003-04/msg00068.html
(other than that it didn't contain a verbose enough explanation)?
Bruno