From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22071 invoked by alias); 26 Aug 2004 14:56:41 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21977 invoked from network); 26 Aug 2004 14:56:36 -0000 Received: from unknown (HELO smtp.hispeed.ch) (62.2.95.247) by sourceware.org with SMTP; 26 Aug 2004 14:56:36 -0000 Received: from indel.ch (217-162-27-127.dclient.hispeed.ch [217.162.27.127]) by smtp.hispeed.ch (8.12.6/8.12.6/tornado-1.0) with SMTP id i7QEuYIu007088 for ; Thu, 26 Aug 2004 16:56:34 +0200 Received: from fabi.indel.ch [192.168.1.19] by indel.ch [127.0.0.1] with SMTP (MDaemon.v2.7.SP5.R) for ; Thu, 26 Aug 2004 16:55:22 +0200 Message-Id: <5.2.0.9.1.20040826163328.01d43c40@NT_SERVER> X-Sender: cenedese@NT_SERVER (Unverified) Date: Thu, 26 Aug 2004 14:56:00 -0000 To: From: Fabian Cenedese Subject: RE: gdb and older cygwins In-Reply-To: References: <412DDD3B.nail3NS112HDC@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MDaemon-Deliver-To: gdb@sources.redhat.com X-Return-Path: cenedese@indel.ch X-SW-Source: 2004-08/txt/msg00389.txt.bz2 >> > 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