Re: Problem with bfd/aclocal.m4

[Alexandre Oliva <aoliva at redhat dot com>]

On Sep  5, 2000, Nick Clifton <nickc@redhat.com> wrote:

> : I could be wrong. But from bfd/Makefile, you should do
> : 
> : # aclocal
> : 
> : to update aclocal.m4.

> Well that should work, but it turns out that the real problem was a
> buggy/extraneous .m4 file in my share/aclocal directory.

Maybe they're not buggy nor erroneous.  Accompanying all `sinclude'
statements in acinclude.m4, there are a couple of AC_DEFUNs that are
ignored by m4, but that are there to satisfy aclocal, and prevent it
from bringing any further m4 macros into aclocal.m4, since we know
they're already defined in the included file.

I have attempted to provide all needed AC_DEFUNs, and tested with more
than one version of aclocal, but it may be that I missed some macro.
In this case, aclocal would pull the m4 file from .../share/aclocal
into aclocal.m4.  And then, since acinclude.m4 includes libtool.m4 and
gettext.m4, you may end up with macros being defined twice.

This would be ok if the macro names were properly quoted, i.e.:

AC_DEFUN([NAME_OF_MACRO],...)

but many people take a shortcut and write:

AC_DEFUN(NAME_OF_MACRO,...)

In this case, if NAME_OF_MACRO is already defined, it is expanded
in-place, before AC_DEFUN is processed, and all the hell breaks
loose.

The following patch to the aclocal perl-script helped me find out
which macros were causing m4 files to be brought into aclocal.m4.
Please take a copy of your aclocal script, apply the patch in the
copy, and let me know which macros cause gettext.m4, lcmessage.m4 or
libtool.m4 from .../share/aclocal to be brought into aclocal.m4.  Or,
even better, post patches to the corresponding acinclude.m4 :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me