[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: m4-1.4.x fails to build git Autoconf for some x (was: branch-1_4 can
From: |
Keith Marshall |
Subject: |
Re: m4-1.4.x fails to build git Autoconf for some x (was: branch-1_4 cannot build Autoconf 2.59 any more) |
Date: |
Mon, 24 Mar 2008 21:34:08 +0000 |
User-agent: |
KMail/1.9.1 |
On Monday 24 March 2008 20:28, Ralf Wildenhues wrote:
> > 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.
>
> It's not clear to me from this description whether it is vanilla m4
> that is broken, or the Autoconf freeze code (and it's just the
> workaround that is in m4). IOW: what would be The Right Thing to do?
That's a tricky one! Maybe a truly native m4 for Win32 really does need
to be O_TEXT; after all that is the native standard for the platform.
However, MSYS aims to provide a bridge between POSIXy build systems and
the native Win32 environment; MSYS is strictly O_BINARY, and problems
do seem to arise, when O_TEXT tools are mixed into the chain.
Microsoft themselves contribute to the confusion, because their C/C++
runtime translates CRLF to LF on input of an O_TEXT stream, and
conversely, translates LF to CRLF on output to such a stream. Thus
MinGW, which is built entirely natively, with O_TEXT for source code
streams, sees only apparently LF streams when reading source files,
regardless of the actual line termination style of the file.
OTOH, because MSYS is strictly O_BINARY, this I/O translation does not
occur, so if an MSYS application reads CRLF input, it gets to see CRLF
and must be prepared to handle it appropriately. When you run autoconf
under MSYS, you use the MSYS O_BINARY perl, and if you add an O_TEXT m4
into the chain, the CRLF line terminations are not correctly handled,
with the CR being interpreted as a component of the data, not of the
line terminator.
Usually, when I'm faced with such issues, I force the input stream to be
O_BINARY, then explicitly handle the line terminations in my own code,
discarding any single CR immediately followed by LF; maybe autoconf
needs to do likewise, in the freezing code, if there is a desire to
support an O_TEXT m4 in conjunction with MSYS.
Regards,
Keith.
- Re: branch-1_4 cannot build Autoconf 2.59 any more, (continued)
- Re: branch-1_4 cannot build Autoconf 2.59 any more, Eric Blake, 2008/03/24
- Re: branch-1_4 cannot build Autoconf 2.59 any more, Ralf Wildenhues, 2008/03/24
- Re: branch-1_4 cannot build Autoconf 2.59 any more, Eric Blake, 2008/03/24
- m4-1.4.x fails to build git Autoconf for some x (was: branch-1_4 cannot build Autoconf 2.59 any more), Ralf Wildenhues, 2008/03/24
- 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, 2008/03/24
- Re: m4-1.4.x fails to build git Autoconf for some x (was: branch-1_4 cannot build Autoconf 2.59 any more), Ralf Wildenhues, 2008/03/24
- 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 <=
- Re: m4-1.4.x fails to build git Autoconf for some x, Eric Blake, 2008/03/25
- Re: m4-1.4.x fails to build git Autoconf for some x, Ralf Wildenhues, 2008/03/25
- Re: m4-1.4.x fails to build git Autoconf for some x, Eric Blake, 2008/03/25
- Re: m4-1.4.x fails to build git Autoconf for some x, Brian Dessent, 2008/03/25