On Sun, 17 Oct 2010, Alex Owen wrote:

<snip>
>>  [ajb@Build32R5 ~]$ rpm -ql autoconf | egrep m4f | xargs egrep 'frozen
>>  state file gen'
>>  /usr/share/autoconf/autoconf/autoconf.m4f:# This is a frozen state
>>  file generated by GNU M4 1.4.5
>>  /usr/share/autoconf/autotest/autotest.m4f:# This is a frozen state
>>  file generated by GNU M4 1.4.5
>>  /usr/share/autoconf/m4sugar/m4sh.m4f:# This is a frozen state file
>>  generated by GNU M4 1.4.5
>>  /usr/share/autoconf/m4sugar/m4sugar.m4f:# This is a frozen state file
>>  generated by GNU M4 1.4.5
>>  [ajb@Build32R5 ~]$
>>
>>  [ajb@Build64R5 ~]$ rpm -ql autoconf | egrep m4f | xargs egrep 'frozen
>>  state file gen'
>>  /usr/share/autoconf/autoconf/autoconf.m4f:# This is a frozen state
>>  file generated by GNU M4 1.4.5
>>  /usr/share/autoconf/autotest/autotest.m4f:# This is a frozen state
>>  file generated by GNU M4 1.4.5
>>  /usr/share/autoconf/m4sugar/m4sh.m4f:# This is a frozen state file
>>  generated by GNU M4 1.4.5
>>  /usr/share/autoconf/m4sugar/m4sugar.m4f:# This is a frozen state file
>>  generated by GNU M4 1.4.5
>>  [ajb@Build64R5 ~]$
>>
>>  As requested, the above is the output returned by 32- & 64-bit RHEL 5.5
>>
>>  Alan.
>> 
> Thanks for that Alan. That confirms that CentOS and RHEL build autoconf 
> against M4 1.4.5
>
> This is a grep form an rpm2cpio unpacked SL5 autoconf rpm
> find ./ |egrep m4f | xargs egrep 'frozen state file gen'
> ./usr/share/autoconf/autoconf/autoconf.m4f:# This is a frozen state file 
> generated by GNU M4 1.4.8
> ./usr/share/autoconf/autotest/autotest.m4f:# This is a frozen state file 
> generated by GNU M4 1.4.8
> ./usr/share/autoconf/m4sugar/m4sh.m4f:# This is a frozen state file generated 
> by GNU M4 1.4.8
> ./usr/share/autoconf/m4sugar/m4sugar.m4f:# This is a frozen state file 
> generated by GNU M4 1.4.8
>
> Thus SL autoconf is built against M4 1.4.8 not M4 1.4.5 like upstream ans so 
> I think that confirms a bug in SL.
> The solution to the bug seems to be to build autoconf on a clean SL5 install 
> (containing the standard SL m4 rpm).
>
> Now of course I am intrigued as to why the build system has a newer m4 
> version on it at all??

When this bit us a few years ago I simply rebuild the sl5 autoconf package 
against the sl5 m4 with that package I get:

$ rpm -ql autoconf | egrep m4f | xargs egrep 'frozen state file gen'
/usr/share/autoconf/autoconf/autoconf.m4f:# This is a frozen state file generated by GNU M4 1.4.5
/usr/share/autoconf/autotest/autotest.m4f:# This is a frozen state file generated by GNU M4 1.4.5
/usr/share/autoconf/m4sugar/m4sh.m4f:# This is a frozen state file generated by GNU M4 1.4.5
/usr/share/autoconf/m4sugar/m4sugar.m4f:# This is a frozen state file generated by GNU M4 1.4.5

and stuff generally works better for rebuilding some other packages that 
use autoconf.  My changelog for the autoconf is prety trivial:

  $ rpm -q autoconf --changelog | head -5
  * Wed Oct 10 2007 Jon Peatfield <[log in to unmask]> - 2.59-12.DAMTP
  - Just rebuild to fix the m4 problem with the SL5x version!

  * Fri Oct 13 2006 Stepan Kasal <[log in to unmask]> 2.59-12
  - Add autoconf-2.59-lock.patch to eliminate a perl warning (#210653).

I had to add something to the version to ensure it is considered newer 
than the sl5 version, and have seen no problems in more than 3 years of 
use.

I seem to remember that the original problem was that the autoconf had 
actually been build on a fedora-6 system rather than sl5.

I *think* I reported this to the list (in 2007), so some archives might 
still have those messages.

-- 
/--------------------------------------------------------------------\
| "Computers are different from telephones.  Computers do not ring." |
|       -- A. Tanenbaum, "Computer Networks", p. 32                  |
---------------------------------------------------------------------|
| Jon Peatfield, _Computer_ Officer, DAMTP,  University of Cambridge |
| Mail:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/ |
\--------------------------------------------------------------------/