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.
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
