From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30795 invoked by alias); 4 Feb 2006 14:52:27 -0000 Received: (qmail 30785 invoked by uid 22791); 4 Feb 2006 14:52:26 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 04 Feb 2006 14:52:23 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F5Olx-0004VK-4l; Sat, 04 Feb 2006 09:52:21 -0500 Date: Sat, 04 Feb 2006 14:52:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: RFA: Support Windows extended error numbers in safe_strerror Message-ID: <20060204145220.GA17011@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200602041435.k14EZ6NK016329@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i 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/msg00073.txt.bz2 On Sat, Feb 04, 2006 at 03:35:06PM +0100, Mark Kettenis wrote: > > I don't know who said "only minimal changes were necessary" but I'm > > sure they were making their best guess at the time. > > In my recollection, Mark Mitchell, did say that. I grudgingly agreed > to having the MinGW32 supprt in and actively worked together with him > to reduce the amount of clutter from #ifdef's and such. It now turns > out even more #ifdef's are needed. Will this ever stop? Mark's an optimist. What can I say? :-) Honestly, I don't think there's much more - this was the big missing feature for cross hosts, any more would be native support and that is more easily compartmentalizable. But the port is still very young, so I do not know. My crystal ball's in the shop. > > 3. Relying on Cygwin to support Windows is awkward for a whole lot > > of reasons, which are in many cases accepted as good ones, and I hope > > that I don't need to rehash right now. But I will if I have to. Just > > ask. > > > > That's why some people do it with Cygwin and some people do it without. > > CodeSourcery has both decided on our own (based on the technical > > merits) and heard unequivocally from our customers that relying on > > Cygwin just isn't going to cut it. > > You may have to refresh my mind. I can see that depending on a third > party library makes life a bit more difficult since you have to > distribute it together with your project, but doesn't MinGW require > you to do something similar? No. MinGW is primarily header files and import stubs for the standard Microsoft DLLs, which are already present on just about any Windows system. I'm not sure if they're all always installed or just most of them are always installed and the others usually installed. A GDB linked to MinGW runs on a clean Windows install; gdb.exe is all you need. It uses kernel32.dll, msvcrt.dll, and ws2_32.dll. > > It might be possible to create a minimalist set of POSIX wrapper > > functions for Windows which were nowhere near as complete as Cygwin, > > were built on top of mingw32, and were moderately more transparent to > > GDB. But I don't think they'd be of much general use besides for GDB, > > because there's real limits to how good an emulation you can manage > > without - surprise! - reinventing Cygwin! See #1 above, please. > > So why aren't you using Cygwin then? It really seems that this was a > bussiness decision rather than a decision made on purely technical > grounds. Sorry, Mark, but did you not read the bit you quoted above? "on or own (based on the technical merits)". It was also a business decision, but there are compelling technical reasons for us not to use Cygwin. For instance, the Cygwin DLL is a sort of "consensual reality", if you'll forgive the analogy. The emulation involves communication between Cygwin processes in some non-obvious ways (to me anyway). One of the consequences is that Cygwin apps get real unhappy when there's multiple copies of Cygwin installed, and there are folks who already use Cygwin (obviously), so installing one's own copy is fragile. And there's vendors of third-party software who ship copies of Cygwin in private directories, or heavily modified, so you can't always rely on the installed copy. Another reason is performance. Not a big issue for GDB, but Cygwin makes a pretty measurable dent in GCC compile times, or at least it did the last time we did measurements. That's another reason we really needed to ship a MinGW toolchain, and having done so there could be even more interoperability problems using it with a Cygwin GDB. -- Daniel Jacobowitz CodeSourcery