[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in gnulib-tools prevents bison from bootstrapping
From: |
Eric Blake |
Subject: |
Re: Bug in gnulib-tools prevents bison from bootstrapping |
Date: |
Fri, 22 Jun 2007 22:25:16 -0600 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Adding bug-autoconf, this thread started here:
http://lists.gnu.org/archive/html/bug-gnulib/2007-06/msg00176.html
Other lists can be trimmed in replies.
According to Hans Aberg on 6/22/2007 7:37 AM:
> On 22 Jun 2007, at 14:55, according to Eric Blake:
>
>> According to Hans Aberg on 6/22/2007 6:13 AM:
>>> Autoconf requires the latest m4, but it actually calls gm4 it seems. So
>>> I installed the latest M4, which ended up in /usr/local/bin/m4 on my
>>> system, and added a soft link
>>> /usr/local/bin/gm4 -> /usr/local/bin/m4
>>> Then it worked.
>>
>> Autoconf finds a working version of GNU m4 as part of its installation
>> process. On your machine, it must have found that gm4 was the correct
>> name for the GNU m4 that was installed at the time you configured
>> autoconf. Alternatives to your symlink proposal, which are somewhat more
>> kosher for system maintainers,
>
> I am not sure the above explanation holds up, because I think I had a
> /usr/local/bin/m4 long before I had a /usr/local/bin/autoconf, and
> others on the Bison list experienced the same problem, but could not
> find its origin.
>
>> would be either reconfiguring and
>> reinstalling autoconf after you installed the more recent GNU m4,
>
> I feel fairly sure I tried that, and it did not help.
If you reconfigured autoconf after installing a newer GNU m4, and autoconf
did not find the right m4, then that is a bug in autoconf, and should be
dealt with there.
>
>> or using
>> the --program-prefix=g option of m4's configure script to install m4
>> as gm4.
>
> My system has a /usr/bison/m4 and a /usr/bin/gm4, but no
> /usr/local/bin/gm4, because later version of M4 odes not install it.
m4 will install as /usr/local/bin/gm4 if you use the --program-prefix=g
option at m4's configure time.
> So
> you need to check what exactly autoconf does, like simply trying to find
> gm4 before trying m4, which would be wrong.
The current algorithm is in autoconf's m4/m4.m4:
AC_PATH_PROGS([M4], [gm4 gnum4 m4], [m4])
AC_CACHE_CHECK([whether m4 supports accurate traces],
...
In other words, during configuration, autoconf finds the first program on
your PATH named gm4, gnum4, and then m4, which also meets the minimum
requirements of m4 1.4.5 or later. If you have suggestions for a better
algorithm, we'd like to know about it.
- --
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGfKCs84KuGfSFAYARAiduAKCgXM6cz8V33ZyTQt+4jaOZC6GmNwCgsh9r
bFwvko5ON29ob2Z9bZupBM8=
=gl7u
-----END PGP SIGNATURE-----
- Re: Bug in gnulib-tools prevents bison from bootstrapping,
Eric Blake <=