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/ | \--------------------------------------------------------------------/