From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13370 invoked by alias); 5 Feb 2006 20:19:09 -0000 Received: (qmail 13361 invoked by uid 22791); 5 Feb 2006 20:19:08 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 05 Feb 2006 20:19:08 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-228-162-73.inter.net.il [84.228.162.73]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DMP67793 (AUTH halo1); Sun, 5 Feb 2006 22:19:03 +0200 (IST) Date: Sun, 05 Feb 2006 20:19:00 -0000 Message-Id: From: Eli Zaretskii To: gdb-patches@sourceware.org In-reply-to: <20060205193440.GB4718@trixie.casa.cgf.cx> (message from Christopher Faylor on Sun, 5 Feb 2006 14:34:40 -0500) Subject: Re: RFA: Support Windows extended error numbers in safe_strerror Reply-to: Eli Zaretskii References: <20060203215455.GA3501@nevyn.them.org> <200602032325.k13NPJ6g028001@elgar.sibelius.xs4all.nl> <20060203233935.GA13238@trixie.casa.cgf.cx> <20060204032730.GB9890@nevyn.them.org> <200602041435.k14EZ6NK016329@elgar.sibelius.xs4all.nl> <20060205001503.GB8728@trixie.casa.cgf.cx> <20060205193440.GB4718@trixie.casa.cgf.cx> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00101.txt.bz2 > Date: Sun, 5 Feb 2006 14:34:40 -0500 > From: Christopher Faylor > > On Sun, Feb 05, 2006 at 06:46:06AM +0200, Eli Zaretskii wrote: > >>Date: Sat, 4 Feb 2006 19:15:03 -0500 > >>From: Christopher Faylor > >> > >>>But it isn't the same platform, anymore than MIPS/Linux and MIPS/Irix > >>>are the same platform. Cygwin requires a considerable amount of > >>>additional software to be installed, of which a large part is a system > >>>library that presents a very different API than the native OS. > >> > >>The minimal amount of software required for gdb to run with Cygwin is: > >>gdb.exe, Cygwin1.dll, cygiconv-2.dll, and cygncurses-8.dll . You may > >>potentially need to have the terminfo library installed, too, don't > >>know for sure, and I'm not really interested in testing. I wouldn't > >>call that a considerable amount of software. > > > >First, I think you need the shell as well (correct me if I'm wrong). > > The shell is needed for the "shell" command. The shell is not used for > running programs. The latter is unlike on Posix platforms, right? > So, yes, if you don't have a Cygwin shell, then the shell command won't > work. If that is a show stopper, I could have gdb revert to using a > windows shell if /bin/sh is missing. I don't know if that's a show-stopper: I don't use Cygwin. But if Cygwin users frequently have a development environment without a shell (which I doubt is the case), then yes, having a workable `shell' command without Bash would be a good change. > >Second, running GDB alone is not useful. People use the Cygwin build > >of GDB to debug other Cygwin programs. Just building those other > >programs requires a more or less full Cygwin installation, including > >the shell, Coreutils, Grep, Gawk, and whatsnot. > > You've lost me. So people *do* (because they can) download a lot of > other packages along with gdb so that means that gdb is unacceptable as > a native debugger? I didn't say that; please re-read the wording you quoted. I said: But it isn't the same platform, anymore than MIPS/Linux and MIPS/Irix are the same platform. Cygwin requires a considerable amount of additional software to be installed, of which a large part is a system library that presents a very different API than the native OS. So this was in the context of discussing the ``2 ports on the same platform'' issue, not GDB being run alone. I'm saying that a Cygwin development environment changes the OS to a degree that it isn't the same system anymore. As another data point, consider this: Emacs now supports a Cygwin build as well as a native Windows build (either with MinGW or MSVC). The amount of Windows-specific code that is common to those two ports is close to nil. > >>Also, there is nothing in Cygwin which stops you from running native > >>windows apps (e.g., a MinGW version of gcc) if that is your preference. > > > >Yes, there is. But I'm sure you know that, so I won't elaborate. > > I'd prefer that you did elaborate since you seem to be implying that I > was (to put it politely) withholding information, and I have no idea > what you're talking about. > > It would not make much sense to think that the existence of the Cygwin > DLL on a windows system would somehow interfere with the correct > operation of a windows program since there are scores of windows > programs running on a correctly functioning Windows system at any given > time. So, you can't mean that, obviously. What I mean is that cooperation between native and Cygwin programs is not easy, to say the least. > If you're talking about trying to run programs under bash, then, the > only problem that I can think of is what Daniel found - some native > Windows programs misbehave if used with Cygwin's ttys or ptys. The > solution to this dilemma is the same that you'd use if Cygwin was not on > the system - don't use ptys or ttys. If you are a purist, then don't > use bash. Just run gdb directly. > > I am not aware of any problems with running native windows programs > under gdb. If there are, then I'd be happy to look into fixing them for > as long as I continue to be maintainer. I'm talking about ttys and ptys. I'm talking about Ctrl-C. I'm talking about incompatible quoting of command-line arguments and &&. I'm talking about mount points and text/binary I/O. Perhaps all this was solved in recent versions of Cygwin, I'm just repeating what I hear from Cygwin users around me. Which is why I didn't want to repeat that hearsay, but you left me no choice. Anyway, this discussion obviously doesn't lead to any constructive direction, so I suggest we drop it. Our disagreements about this were not born yesterday. Let's concentrate on the common goals, not on disagreements.