This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: Support Windows extended error numbers in safe_strerror
> Date: Wed, 8 Feb 2006 16:13:49 -0500
> From: Bob Rossi <bob@brasko.net>
>
> 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 <drow@false.org>
> > >
> > > 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