bug-libtool
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]