bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autoconf-2.62 doesn't build on RHEL4


From: Eric Blake
Subject: Re: autoconf-2.62 doesn't build on RHEL4
Date: Tue, 22 Apr 2008 14:32:15 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Ralf Corsepius <rc040203 <at> freenet.de> writes:

> > 
> > You're comparing apples and oranges. 
> I don't see this ... You require a particular version of gm4 instead of
> searching for a feasible, sufficient "m4" (note: m4 vs. gm4).

Autoconf has REQUIRED working trace and frozen file support for years now 
(tracing since the release of autoconf 2.50); it's just that prior to autoconf 
2.62, you had silent output corruption rather than verbose up-front failure if 
you failed to meet this requirement.  Prior to 1.4.5, gm4's tracing was buggy, 
and could result in autoconf outputting corrupt configure files.  And note that 
we are NOT searching for a particular version or vendor for m4, rather, we 
followed our own advice and added a feature test in 2.62 - ANY m4 that passes 
this test is good enough:
http://git.sv.gnu.org/gitweb/?p=autoconf.git;a=blob;f=m4/m4.m4;h=f27d8c0

But to my knowledge, no m4 other than GNU m4 1.4.4b or newer currently passes 
this test, and 1.4.4b was only a beta release, so when the test fails, we 
advise GNU m4 1.4.5 or newer.  BSD m4, which supports a moderate degree of 
tracing, does not yet support frozen files, but if someone were to fix it to do 
so, then BSD m4 would be a viable alternative.  And if a distro wants to 
backport JUST the patch that made tracing work in m4 1.4.4b, but leave 
everything else in the state of gm4 1.4.1, that would also work.

As it stands, this test is incomplete for autoconf's true requirements; it 
fails to reject gm4 1.4.10 on BSD-based platforms (there are documented reports 
of m4 1.4.10 generating corrupt configure files on platforms where
fopen(name,"a+") sets the file offset to the end, like OpenBSD or darwin, 
rather than the beginning, like Linux or cygwin).  But because I made the 
release of m4 1.4.11 prior to the release of autoconf 2.62, I didn't spend time 
trying to figure out how to enhance the test to accurately flag the m4 1.4.10 
bug, on the assumption that anyone installing a newer m4 to meet autoconf's 
requirements would either stick with the minimum of 1.4.5 or probably go all 
the way to 1.4.11.

-- 
Eric Blake






reply via email to

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