Re: m4-1.4.x fails to build git Autoconf for some x (was: branch-1_4 cannot build Autoconf 2.59 any more)

[Keith Marshall]

On Monday 24 March 2008 16:51, Ralf Wildenhues wrote:
> On Mon, Mar 24, 2008 at 07:10:24AM -0600, Eric Blake wrote:
> > I'll try looking into the MinGW failure, but I'm not sure how long
> > it will take me to reproduce it (I don't normally build in MinGW;
>
> Here's some more data.  I installed MinGW's m4-1.4.7 which works
> fine. It has this diff over vanilla GNU m4-1.4.7.

If I may butt in here: am I correct in interpreting this to mean that 
you can successfully build autoconf, if you use the *MSYS* prebuild of 
m4-1.4.7, but if you use MinGW to build a vanilla GNU m4, (1.4.7 or 
later), that it fails?  If so, then this has been my experience too.  
The problem arises because the vanilla build with MinGW leaves the 
stdio streams in O_TEXT mode, resulting in CRLF output, whereas the 
MSYS build uses O_BINARY mode for these streams, resulting in just LF 
output; the residual CRs from O_TEXT output seem to confuse the 
autoconf build process, in the freezing stage.

> The MSYS builds are special (dunno if you knew)

Yes; they are more akin to Cygwin builds, relying on the msys-1.0.dll 
runtime, (a minimal fork of Cygwin-1.3 runtime), rather than the native 
Win32 runtime used by MinGW.

> and you are _not_ supposed to introduce the config.{guess,sub} changes
> into packages outside of mingw.org,

That is something that Earnie has requested; I don't feel quite so 
strongly about it, but I do think that if the MSYS info is to be there, 
it should at least be correct.  I do notice that someone, without any 
official sanction from the MinGW Project seems to have submitted 
patches to include it, *incorrectly*.  Earnie did ask that this 
erroneous info be removed, but last time I looked, it still appeared to 
be present, and incorrect as ever.

> but the freeze.c change might be worth looking at, see below.
>
> FWIW, with the freeze.c change alone, Autoconf still failed to build
> however.  The failure is due to "freezing produced output", notably
> lines consisting of little more than CR, and I have not yet seen a
> simple way to avoid it; just killing \r in autom4te.in leads to
>
> | autom4te_perllibdir='../../autoconf'/lib
> | AUTOM4TE_CFG='../lib/autom4te.cfg'         ../bin/autom4te -B
> | '..'/lib -B '../../autoconf'/lib         --language=M4sh
> | ../../autoconf/tests/wrapper.as -o wrapper.in
> | C:\msys\1.0\home\ralf\local\bin\m4.exe: premature end of frozen
> | file autom4te: /home/ralf/local/bin/m4.exe failed with exit status:
> | 1
>
> Maybe this still helps.  I don't know who wrote the patch, likely
> Earnie or Keith,

If you are referring to the MSYS custom build, this was actually 
provided by Chuck Wilson, a Cygwin developer who has also made 
invaluable contributions to MSYS.

> but you'll be able to find that out either on 
> mingw.org or one of its mailing lists.
>
> Anyway, using MinGW's m4-1.4.7, Autoconf builds fine, and the
> testsuite shows no errors.  I will thus not look into this issue any
> further, it likely being no Autoconf regression.

No, I'm fairly sure the problem is in vanilla GNU m4 building with 
O_TEXT mode for the stdio streams.  Built this way, IIRC, it fails 
every single one of its own testsuite checks, and in every case, it 
fails because the test compares CRLF output to LF only reference data, 
and the two are of course different.  I myself built m4-1.4.9, with a 
Q&D patch to _setmode the stdio streams to O_BINARY, and to open any 
subsequent streams with this same mode; this was a significant 
improvement, but still didn't achieve 100% success; Chuck's MSYS build 
seemed more successful, so I didn't pursue it further.

> Note however that it is a significant hassle to get msysgit installed
> in order to get Autoconf bootstrapped from git sources so that it
> doesn't report a --version of UNKNOWN.

We don't provide any msysgit package, that I'm aware of.  Where did it 
come from?  It would appear to be developed independently of the MinGW 
Project, and therefore without the assistance of the main pool of 
experienced MSYS developers.

Regards,
Keith.