Re: can't use m4-1.4.8 in Mingw in Windows XP(gcc-3.4.5)

[haibin zhang]

--- Eric Blake <address@hidden>写道:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> [You can probably drop bug-autoconf and bug-automake
> from your replies]
> 
> According to haibin zhang on 11/22/2006 4:36 AM:
> > HI All:
> > Just now I can't use m4-1.4.8 in Mingw in Windows
> XP( I can compile
> > it,but can't be used)
> 
> It worked fine for me to cross-compile on cygwin
> targetting mingw; in
> fact, that was one of my criteria for a successful
> release.  I haven't
> changed any line-ending behavior in the 1.4.x
> series, so 1.4.8 should
> behave similarly to prior versions of m4 compiled
> for mingw.
> 

I have talked with Mingw team, they told me that
m4-1.4.8 can be used in gcc-2.95.3 and can't be used
in gcc-3.4.5 , beacuse of IO with CRLF line endings.

gcc-2.95.3 default use LF only line endings, but
gcc-3.4.5 default use CRLF line endings.

I have checked m4-1.4.8 source, it don't support
Mingw32  directly. it only support cygwin32

Can you define mingw32 MICRO , when checked mingw32
head, then change IO to binary mode

Regards

Zhang HaiBin

The following line is mingw team talk view
====================================================
On Sunday 08 July 2007 16:04, haibin zhang wrote:
> As I know , you must build m4-1.4.9 with gcc-2.95.3,
> It can't work when you build with gcc-3.4.X.

No, this is not the case.  Yes, there is a problem,
but your evaluation
 
is completely wrong.  You keep making these wild
assessments, without 
presenting any form of corroborating evidence; let
*me* make a wild 
guess: your gcc-2.95.3 is the MSYS development
compiler; gcc-3.4.x is a
 
MinGW compiler, which is unsuitable for building MSYS
components.

> I have reported the bug to m4 team , but they said
> they can't help me to resolve this problem.

Nor should they, on the basis of your inadequate
problem assessment.

> why m4-1.4.X can work building with gcc-2.95.3, but
> can't work building with gcc-3.4.X, I guess that the
> error is maybe ��in path resolve

Nope.  You are way off beam here; it has nothing to do
with path 
resolution.  The difference is in binary mode versus
text mode for 
standard stream I/O.

> I guess that m4-1.4.X can resolve path /usr/bin as
> /usr/bin in gcc-2.95.3 , but it many resolve path
> /usr/bin as c:/msys/bin in gcc-3.4.X , so m4-1.4.X
> can't be used .

Again, no.  When you build with the MSYS development
compiler, I/O 
defaults to binary, with LF only line endings; when
you build with a 
MinGW compiler, the default is text, hence CRLF line
endings.  Those 
line ending differences completely explain the failure
of the MinGW 
built m4-1.4.9 to work correctly with autoconf.  If I
patch m4-1.4.9 
sources, to force all standard streams, and all files
opened by m4, to 
binary mode, then recompile with MinGW's 3.4.5
compiler, the resulting 
m4.exe seems to work perfectly well with
autoconf-2.61.  However, the 
resulting m4 build does then fail four of its
testsuite checks; in each
 
case, the reported failure does appear to be related
to CRLF vs. LF 
distinctions, for in each of the four cases, the
expected and actual 
output appear identical to the naked eye; 
====================================================


      ___________________________________________________________ 
抢注雅虎免费邮箱3.5G容量，20M附件！ 
http://cn.mail.yahoo.com