From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20248 invoked by alias); 26 Aug 2004 14:23:43 -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 20230 invoked from network); 26 Aug 2004 14:23:39 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sourceware.org with SMTP; 26 Aug 2004 14:23:39 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0); Thu, 26 Aug 2004 15:20:40 +0100 From: "Dave Korn" To: "'Michael Chastain'" , , Subject: RE: gdb and older cygwins Date: Thu, 26 Aug 2004 14:23:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <412DDD3B.nail3NS112HDC@mindspring.com> Message-ID: X-OriginalArrivalTime: 26 Aug 2004 14:20:40.0796 (UTC) FILETIME=[DD92A1C0:01C48B77] X-SW-Source: 2004-08/txt/msg00388.txt.bz2 > -----Original Message----- > From: gdb-owner n Behalf Of Michael Chastain > Sent: 26 August 2004 13:53 > To: gdb; Cenedese > Subject: Re: gdb and older cygwins > > Fabian Cenedese wrote: > > 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?] > I can think of six strategies to try: > (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. > (3A) Change every occurence of "open" to include O_TEXT as part > of the mode. That is what O_TEXT is for! It ought to work > great, except that it only works on systems that actually > support O_TEXT, like Cygwin. You would still not be able to > compile your "\r\n" files on a non-Cygwin system with > gcc 2.95.3. 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 for evidence that this approach is known to work with gcc-2.95.3 under cygwin; see http://www.mail-archive.com/cygwin-apps@sources.redhat.com/msg00022.html for a clear explanation of what these various object files (textmode.o, binmode.o, automode.o) do. > (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. cheers, DaveK -- Can't think of a witty .sigline today....