From: Werner L. <wl...@gn...> - 2012-01-29 12:06:21
|
Folks, after a few hours of debugging I've discovered that either MinGW awk 3.1.7 or MinGW autoconf 2.68's awk script as used in `config.status' (to convert `foo.h.in' into `foo.h') has problems with CRLF: Only if the original input file has Unix line endings, the script runs successfully! Otherwise, no substitution of #undef HAVE_FOO_H into #define HAVE_FOO_H (and similar lines) happens. Is this expected behaviour? I have simply checked out the FreeType git repository and run its `autogen.sh' script, and by default git converts text files to CRLF on Windows. The above is a very unpleasant surprise. Werner |
From: Earnie B. <ea...@us...> - 2012-01-29 18:28:28
|
On Sun, Jan 29, 2012 at 7:05 AM, Werner LEMBERG <wl...@gn...> wrote: > > Folks, > > > after a few hours of debugging I've discovered that either MinGW awk > 3.1.7 or MinGW autoconf 2.68's awk script as used in `config.status' > (to convert `foo.h.in' into `foo.h') has problems with CRLF: Only if > the original input file has Unix line endings, the script runs > successfully! Otherwise, no substitution of > > #undef HAVE_FOO_H > > into > > #define HAVE_FOO_H > > (and similar lines) happens. > > Is this expected behaviour? I have simply checked out the FreeType > git repository and run its `autogen.sh' script, and by default git > converts text files to CRLF on Windows. The above is a very > unpleasant surprise. Yes, MSYS is set to use LF line endings. You can use the dos2unix script to convert the files. How did CRLF get there anyway? How did you extract or obtain the source? -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Werner L. <wl...@gn...> - 2012-01-29 18:57:48
|
> Yes, MSYS is set to use LF line endings. OK. In other words, it is a problem of the awk script in `config.status' which doesn't anticipate the CRLF case within a Unix line ending environment... And indeed, if I read the correctly correctly, the $ac_cs_awk_cr stuff or something similar is missing for the `defines.awk' script (within `config.status'). > How did CRLF get there anyway? How did you extract or obtain the > source? `git clone' using msysgit, which uses CRLF by default for checkout (provided the files are stored as LF within git, as it is for my repository). I know how to circumvent the problem, but I was fooled by the `msys' part in msysgit's name, thinking that those MSYS and msysgit fit together without additional tweaks... Thanks for your help. Werner |
From: Eli Z. <el...@gn...> - 2012-01-29 19:24:23
|
> Date: Sun, 29 Jan 2012 19:57:33 +0100 (CET) > From: Werner LEMBERG <wl...@gn...> > Cc: bug...@gn... > > > How did CRLF get there anyway? How did you extract or obtain the > > source? > > `git clone' using msysgit, which uses CRLF by default for checkout > (provided the files are stored as LF within git, as it is for my > repository). I know how to circumvent the problem, but I was fooled > by the `msys' part in msysgit's name, thinking that those MSYS and > msysgit fit together without additional tweaks... You should set up msysgit to leave the EOLs alone. When you installed msysgit, it offered that as an option. In fact, I think this is the default, but maybe I'm wrong. In any case, letting a VCS change the EOL format is asking for trouble. |
From: asmwarrior <asm...@gm...> - 2012-01-30 00:53:31
|
On 2012-1-30 3:21, Eli Zaretskii wrote: >> Date: Sun, 29 Jan 2012 19:57:33 +0100 (CET) >> From: Werner LEMBERG<wl...@gn...> >> Cc: bug...@gn... >> >>> How did CRLF get there anyway? How did you extract or obtain the >>> source? >> >> `git clone' using msysgit, which uses CRLF by default for checkout >> (provided the files are stored as LF within git, as it is for my >> repository). I know how to circumvent the problem, but I was fooled >> by the `msys' part in msysgit's name, thinking that those MSYS and >> msysgit fit together without additional tweaks... > > You should set up msysgit to leave the EOLs alone. When you installed > msysgit, it offered that as an option. In fact, I think this is the > default, but maybe I'm wrong. In any case, letting a VCS change the > EOL format is asking for trouble. > > I have meet this issue for several times when building gdb under MSYS+MinGW, and this really wastes a lot of time until I finally debug to find that MSYSGIT just automatically change the EOL, and CRLF can't be handled by autotools/awk/sed system. There is an option to force MSYSGIT not do such conversion. see: http://progit.org/book/ch7-1.html > Git can handle this by auto-converting CRLF line endings into LF when you commit, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true — this converts LF endings into CRLF when you check out code: > > $ git config --global core.autocrlf true So, you should set this option to "false" here. When you reinstall or upgrade your msysgit (I usually use portable Msysgit), don't forget to do this, otherwise you will meet this issue again. asmwarrior ollydbg from codeblocks' forum |
From: Werner L. <wl...@gn...> - 2012-01-30 05:24:11
|
> I have meet this issue for several times when building gdb under > MSYS+MinGW, and this really wastes a lot of time until I finally > debug to find that MSYSGIT just automatically change the EOL, and > CRLF can't be handled by autotools/awk/sed system. Well, I'm new to MinGW, so I trapped into this. However, I wonder, even if MSYS defaults to LF (which I think is a good thing), whether autotools can't be made work smoothly even with CRLF. Mind you that everything went fine with libtool, automake, and autoconf in an CRLF environment *except* this substitution. So it seems to me that it is an oversight in the autoconf implementation. > There is an option to force MSYSGIT not do such conversion. [...] Yep, I'm now using this. Werner |
From: Earnie B. <ea...@us...> - 2012-01-30 17:00:49
|
On Mon, Jan 30, 2012 at 12:23 AM, Werner LEMBERG wrote: > >> I have meet this issue for several times when building gdb under >> MSYS+MinGW, and this really wastes a lot of time until I finally >> debug to find that MSYSGIT just automatically change the EOL, and >> CRLF can't be handled by autotools/awk/sed system. > > Well, I'm new to MinGW, so I trapped into this. However, I wonder, > even if MSYS defaults to LF (which I think is a good thing), whether > autotools can't be made work smoothly even with CRLF. Mind you that > everything went fine with libtool, automake, and autoconf in an CRLF > environment *except* this substitution. So it seems to me that it is > an oversight in the autoconf implementation. > No. This isn't an oversite. MSYS, Cygwin, *nix systems expect LF line endings. It isn't up to the script to interpret the CRLF, what happens is CR becomes a part of the line and is in the way. You should never need to be concerned with CRLF if your tools are set correctly. The default for MSYSGIT for autocrlf should be set to FALSE. That is the real issue. >> There is an option to force MSYSGIT not do such conversion. [...] > > Yep, I'm now using this. Good. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Werner L. <wl...@gn...> - 2012-01-30 19:14:44
|
>> No. This isn't an oversite. MSYS, Cygwin, *nix systems expect LF >> line endings. It isn't up to the script to interpret the CRLF, >> what happens is CR becomes a part of the line and is in the way. >> You should never need to be concerned with CRLF if your tools are >> set correctly. Here I fully agree. BUT: I think the right solution is to make GNU tools work with both LF and CRLF line endings. It seems that we disagree here. > The default for MSYSGIT for autocrlf should be set to FALSE. That > is the real issue. Yep. > If setting msysgit's EOL translation off doesn't fix the problem, > then the other possible reason is that some MSYS tool is missing > (not installed), and the corresponding MinGW/GnuWin32 tool is > invoked instead. Fortunately, this wasn't a problem for me. Werner |
From: LRN <lr...@gm...> - 2012-01-30 20:51:05
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30.01.2012 23:14, Werner LEMBERG wrote: > >>> No. This isn't an oversite. MSYS, Cygwin, *nix systems expect >>> LF line endings. It isn't up to the script to interpret the >>> CRLF, what happens is CR becomes a part of the line and is in >>> the way. You should never need to be concerned with CRLF if >>> your tools are set correctly. > > Here I fully agree. BUT: I think the right solution is to make > GNU tools work with both LF and CRLF line endings. It seems that > we disagree here. > Lots of work, little gain. Use LF-compatible text editors, or use dos2unix (when processing files from outside) - and you'll be fine. MSys is a crutch to run *nix shell scripts on W32, making it more W32-compatible (such as forcing it to interpret CRLF as LF) feels kinda wrong. If you have script files generated on W32, you might as well use proper W32-compatible tools instead of MSys... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPJwKsAAoJEOs4Jb6SI2CwatgH/jxpb+cRXqeE67s/Fqpp5y3b GKsy54J2rSFkxePC2lwkuWsRh0Yl41KRfaXAvFBem/TxE6ld+N+KtW74HggzXcoi U6bzxNuBDlgdlbVZf6KRJus98KtcDRybD3imOTlQvh3vhOlgOrBEGidUAranlNR1 lu8rNVAuZVDcjoM8/Ab+dJu+gvb8OUWHXqNlvtCECZGVVtwwbGP8mbOTW8BS8kHl LIxKv5W/2m5LtHmOpD+32UVAZf/Fg0RrsaHjvBDNp/tKY01CMxJW01okzOKg2m/8 2M91GeWP+4lTdTkEYpVLATyIaXbiBcPqGp6IVK+ycsDKrRt0NqrdQT1gWPaVlHI= =ER7M -----END PGP SIGNATURE----- |
From: Eli Z. <el...@gn...> - 2012-01-30 21:19:08
|
> Date: Mon, 30 Jan 2012 20:14:25 +0100 (CET) > From: Werner LEMBERG <wl...@gn...> > > > >> No. This isn't an oversite. MSYS, Cygwin, *nix systems expect LF > >> line endings. It isn't up to the script to interpret the CRLF, > >> what happens is CR becomes a part of the line and is in the way. > >> You should never need to be concerned with CRLF if your tools are > >> set correctly. > > Here I fully agree. BUT: I think the right solution is to make GNU > tools work with both LF and CRLF line endings. If that's what you want, use MinGW builds, not MSYS builds of the tools. MSYS is specifically about Unix-like behavior, and on Unix CR is just a character, even if it precedes an LF. MSYS is there to let you run Unix scripts and read text files as the same tools would do on Unix. |
From: Earnie B. <ea...@us...> - 2012-01-30 21:58:36
|
On Mon, Jan 30, 2012 at 4:17 PM, Eli Zaretskii <el...@gn...> wrote: >> Date: Mon, 30 Jan 2012 20:14:25 +0100 (CET) >> From: Werner LEMBERG <wl...@gn...> >> >> >> >> No. This isn't an oversite. MSYS, Cygwin, *nix systems expect LF >> >> line endings. It isn't up to the script to interpret the CRLF, >> >> what happens is CR becomes a part of the line and is in the way. >> >> You should never need to be concerned with CRLF if your tools are >> >> set correctly. >> >> Here I fully agree. BUT: I think the right solution is to make GNU >> tools work with both LF and CRLF line endings. > > If that's what you want, use MinGW builds, not MSYS builds of the > tools. MSYS is specifically about Unix-like behavior, and on Unix CR > is just a character, even if it precedes an LF. MSYS is there to let > you run Unix scripts and read text files as the same tools would do on > Unix. And adding more work to MSYS for little gain is a "won't fix". The only tool that I modified in previous releases was sed but I don't know if that change has carried forward into future releases since I no longer maintain it. Actually I forget exactly what the change did but IIRC it was related to making CR act as a white space character. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Eli Z. <el...@gn...> - 2012-01-30 18:11:46
|
> Date: Mon, 30 Jan 2012 12:00:38 -0500 > From: Earnie Boyd <ea...@us...> > > No. This isn't an oversite. MSYS, Cygwin, *nix systems expect LF > line endings. It isn't up to the script to interpret the CRLF, what > happens is CR becomes a part of the line and is in the way. You > should never need to be concerned with CRLF if your tools are set > correctly. The default for MSYSGIT for autocrlf should be set to > FALSE. That is the real issue. If setting msysgit's EOL translation off doesn't fix the problem, then the other possible reason is that some MSYS tool is missing (not installed), and the corresponding MinGW/GnuWin32 tool is invoked instead. |
From: Dieter V. <di...@op...> - 2012-01-31 11:03:58
|
On Mon, 30 Jan 2012 20:09:16 +0200, Eli Zaretskii wrote: > If setting msysgit's EOL translation off doesn't fix the problem, > then > the other possible reason is that some MSYS tool is missing (not > installed), and the corresponding MinGW/GnuWin32 tool is invoked > instead. In my experience, changes to core.autocrlf only seem to take full effect on newly initialized or cloned repositories so you might want to try a fresh clone and see what happens... mvg, Dieter |