This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]