From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25261 invoked by alias); 8 Feb 2006 23:10:41 -0000 Received: (qmail 25227 invoked by uid 22791); 8 Feb 2006 23:10:37 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 08 Feb 2006 23:10:34 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k18NARDh008439; Thu, 9 Feb 2006 00:10:27 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id k18NARiv018321; Thu, 9 Feb 2006 00:10:27 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k18NAQNe027038; Thu, 9 Feb 2006 00:10:26 +0100 (CET) Date: Wed, 08 Feb 2006 23:10:00 -0000 Message-Id: <200602082310.k18NAQNe027038@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: eliz@gnu.org CC: gdb-patches@sourceware.org In-reply-to: (message from Eli Zaretskii on Wed, 08 Feb 2006 23:54:36 +0200) Subject: Re: RFA: Support Windows extended error numbers in safe_strerror References: <20060203215455.GA3501@nevyn.them.org> <20060206173550.GB22947@nevyn.them.org> <200602062254.k16MsagK009925@elgar.sibelius.xs4all.nl> <20060206225829.GA31895@nevyn.them.org> <20060208000855.GA5040@nevyn.them.org> <200602082107.k18L7xRh013417@elgar.sibelius.xs4all.nl> 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/msg00191.txt.bz2 > Date: Wed, 08 Feb 2006 23:54:36 +0200 > From: Eli Zaretskii > > > Date: Wed, 8 Feb 2006 22:07:59 +0100 (CET) > > From: Mark Kettenis > > CC: gdb-patches@sourceware.org > > > > I really think that we should drop MinGW support, and that the people > > who want GDB on windows should work on fixing the apparent problems > > with Cygwin. > > [...] > > My dislike for this stuff is probably there because where I've been > > cleaning out much of the host-specific quirks, this MinGW support > > seems to add back a lot special tweaks, and since Windows is so > > different from Unix-like systems, there's absolutely no hope, things > > can be unified. That, together with the reintroduction of xm.h, seems > > like a giant leap backwards to me. I really don't like that xm.h is > > back now, since it sets a precedent. People have used these files for > > quick hacks in the past, and the new xm.h will make it harder to tell > > people that's not acceptable. I think there is a better approach > > though. How about having the implementation of safe_strerror() and > > gdb_select() in mingw-hdep.c and move the (trivial) existing > > implementations of these functions to a new posix-hdep.c? > > > > Speaking about gdb_select(), a really bad thing about your patch is > > that we now have gdb_select(), but that some code still uses select() > > and that the difference matters! > > Mark, can you please make up your mind whether you are talking about > coding and design issues, or about ideology? If the problem is xm.h > and the select vs gdb_select dichotomy, those are technical problems > for which I have no doubt that we will find good solutions. In > particular, I firmly believe, based in no small part on my experience > of porting GNU software, that your fears of there being ``absolutely > no hope'' to have clean sources _and_ MinGW support--that these fears > have no real basis, because similar problems were solved elsewhere > more than once. > > But if the problem is that you object in principle to having MinGW > support as part of the official codebase, then no amount of coding by > Daniel or anyone else will ever get your approval. > > Which one is it? I'd rather see us drop the attempt to support MinGW, but if we don't I want to make sure the MinGW support is integrated in such a way that its impact on the rest of the code is as small as possible. Mark