From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28036 invoked by alias); 8 Feb 2006 23:17:43 -0000 Received: (qmail 28025 invoked by uid 22791); 8 Feb 2006 23:17:42 -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:17:41 +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 k18NG3TM016896; Thu, 9 Feb 2006 00:16:03 +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 k18NG350011118; Thu, 9 Feb 2006 00:16:03 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id k18NG28Q031774; Thu, 9 Feb 2006 00:16:02 +0100 (CET) Date: Wed, 08 Feb 2006 23:17:00 -0000 Message-Id: <200602082316.k18NG28Q031774@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: bob@brasko.net CC: drow@false.org, gdb-patches@sourceware.org In-reply-to: <20060208211349.GH3975@brasko.net> (message from Bob Rossi on Wed, 8 Feb 2006 16:13:49 -0500) 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> <20060208211349.GH3975@brasko.net> 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/msg00192.txt.bz2 > Date: Wed, 8 Feb 2006 16:13:49 -0500 > From: Bob Rossi > > On Wed, Feb 08, 2006 at 10:07:59PM +0100, Mark Kettenis wrote: > > > Date: Tue, 7 Feb 2006 19:08:55 -0500 > > > From: Daniel Jacobowitz > > > > > > On Mon, Feb 06, 2006 at 05:58:29PM -0500, Daniel Jacobowitz wrote: > > > > Could you explain why you don't like this one a little more clearly? > > > > > > > > Of course it'd be possible to write a complete replacement; I'd just > > > > replace the call to the system strerror with a switch statement and > > > > copy the strings out of the system runtime, or out of some other > > > > standard source. But I don't see why that's any better than this, and > > > > it's gratuituous duplication of information, so I'd like to understand > > > > what you dislike about it. > > > > > > > > If it's the #define strerror that you dislike, two comments: > > > > > > > > - I could put an #ifdef around the one and only call to strerror > > > > instead, in utils.c. I'd be perfectly happy with that. > > > > > > > > - I can't override the system strerror by defining my own copy; that > > > > would be prone to breakage due to the workings of > > > > __attribute__((dllimport)). I discussed that with Chris before posting > > > > this version. > > > > > > Hi Mark, > > > > > > Have you had a chance to think about this? I realize it's only been a > > > day, but I'm trying not to let these patches linger too long. I'd > > > really like to understand what folks dislike about this patch, so > > > that I can improve it. Same for the other patch; I replied to you > > > about select. > > > > 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. I cannot image that Cygwin is unique in having "DLL > > hell" problem. People certainly must have found a proper solution for > > this by now. > > When I say that there is not a nice way to deliver a Cygwin1.dll, I > mean it. It's not a dll hell problem. If anyone can say that this is not > true, please let me know. I'm dieing to hear the answer. > > You simply can not have 2 Cygwin1.dll's on the same system and there is > no way that I can see to prevent it from happening. I always understood having two different versions of a DLL with the same name as being the "DLL hell" problem. Am I wrong? I can't believe that in the last 10 years that people have been talking about this problem, MicroSoft didn't come up with a solution for it. And even if they didn't, the solution is simple: just ship the Cygwin DLL's under a different name. Or just link the Cygwin code statically. Or is that impossible on Windows? Mark