RE: gdb and older cygwins

[Fabian Cenedese <Cenedese at indel dot ch>]

>> > PS: The other solution would be to fix the 2.95.3 source about this
>> > CRLF bug. I looked into the gcc list but couldn't find 
>> simple patches,
>> > I guess it needs a bigger change. If anyone has some hints 
>> about it...
>
>  My first hint is this:  never use WinZIP to unpack a tarball in a cygwin
>environment, because it does the wrong thing with soft-links and it mangles
>all the line endings.  Use "tar xfv" instead.
>
> [Did I guess correctly how you managed to get your gcc sources mangled?]

It depends. I use cygwin only to compile gcc/gdb+co. The intended platform
to use them is Windows with cygwin.dll, not the whole Cygwin system. So
the source files which gcc will need to cope with ARE Windows text files.

The source files for gcc and gdb of course I didn't unpack with Winzip,
and if it's only because it doesn't understand tar/gz/bzip2 :)

>> (2)  Hack on safe_read so that it converts "\r\n" => "\n".
>>      Essentially you need to allocate a private buffer,
>>      do the raw read into the private buffer, and then translate
>>      from the private buffer to the caller-supplied buffer.
>> 
>>      A problem occurs when the '\r' happens at the end of one
>>      read and the '\n' happens at the beginning of the next read.
>
>  Actually there's no need to do anything so complex at all.  Since the size
>of the processed data will always be less than the size of the original
>data, because all we ever do is remove '\r' bytes, you can just read it
>directly into the caller-supplied buffer and post-process it in situ.  As to
>the second part of the problem, well, given that this routine only has to
>handle text input to a compiler, and not general binary files, and assuming
>that not being able to parse mac-style CR-only line ends won't be a problem,
>you really only need to delete every '\r' and not even care whether there's
>a '\n' following or not, nor whether there might happen to be a \r\n split
>across two reads.

I might not even need to do that as other solutions are even simpler. But
I'll still keep it in mind.

>  Cygwin provides a cunning way to avoid having to hack on the sources to to
>this.  Simply link with the cygwin standard library file /lib/textmode.o and
>it will intercept all calls to open and add the O_TEXT flag for you.  See 
>
>http://www.cygwin.com/ml/cygwin/2002-10/msg00172.html

Looks also good. But the mentioned option 3B (redefine open) already seems
to do the trick. But I need to test some more. Ld seems to do something
wrong... Better recompile everything :)

>> (5) Mount your Cygwin filesystems with the "text" option.
>>     All Cygwin programs will see "\n" line endings instead of
>>     "\r\n".  This is likely to fix the problems with gcc,
>>     but cause other random problems with other random programs.
>
>  Instead, just create a textmode mountpoint solely for the gcc source
>directory.  That way nothing else should be affected.  Note that you'll have
>to give an absolute path to configure when you invoke it, or use the
>--srcdir= argument to configure to specify the mountpoint rather than any
>other equivalent but non-textmode path to the sources.

As I will use gcc and gdb from Windows (and not in Cygwin) I guess
this is no option for me.

Thanks

bye  Fabi