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, 08 Feb 2006 23:54:36 +0200
> From: Eli Zaretskii <eliz@gnu.org>
>
> > Date: Wed, 8 Feb 2006 22:07:59 +0100 (CET)
> > From: Mark Kettenis <mark.kettenis@xs4all.nl>
> > 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