Re: RFA: Support Windows extended error numbers in safe_strerror

[Daniel Jacobowitz <drow at false dot org>]

On Sat, Feb 04, 2006 at 03:35:06PM +0100, Mark Kettenis wrote:
> > I don't know who said "only minimal changes were necessary" but I'm
> > sure they were making their best guess at the time.
> 
> In my recollection, Mark Mitchell, did say that.  I grudgingly agreed
> to having the MinGW32 supprt in and actively worked together with him
> to reduce the amount of clutter from #ifdef's and such.  It now turns
> out even more #ifdef's are needed.  Will this ever stop?

Mark's an optimist.  What can I say?  :-)

Honestly, I don't think there's much more - this was the big missing
feature for cross hosts, any more would be native support and that
is more easily compartmentalizable.  But the port is still very
young, so I do not know.  My crystal ball's in the shop.

> > 3.  Relying on Cygwin to support Windows is awkward for a whole lot
> > of reasons, which are in many cases accepted as good ones, and I hope
> > that I don't need to rehash right now.  But I will if I have to.  Just
> > ask.
> > 
> > That's why some people do it with Cygwin and some people do it without.
> > CodeSourcery has both decided on our own (based on the technical
> > merits) and heard unequivocally from our customers that relying on
> > Cygwin just isn't going to cut it.
> 
> You may have to refresh my mind.  I can see that depending on a third
> party library makes life a bit more difficult since you have to
> distribute it together with your project, but doesn't MinGW require
> you to do something similar?

No.  MinGW is primarily header files and import stubs for the standard
Microsoft DLLs, which are already present on just about any Windows
system.  I'm not sure if they're all always installed or just most of
them are always installed and the others usually installed.

A GDB linked to MinGW runs on a clean Windows install; gdb.exe is all
you need.  It uses kernel32.dll, msvcrt.dll, and ws2_32.dll.

> > It might be possible to create a minimalist set of POSIX wrapper
> > functions for Windows which were nowhere near as complete as Cygwin,
> > were built on top of mingw32, and were moderately more transparent to
> > GDB.  But I don't think they'd be of much general use besides for GDB,
> > because there's real limits to how good an emulation you can manage
> > without - surprise! - reinventing Cygwin!  See #1 above, please.
> 
> So why aren't you using Cygwin then?  It really seems that this was a
> bussiness decision rather than a decision made on purely technical
> grounds.

Sorry, Mark, but did you not read the bit you quoted above?  "on or own
(based on the technical merits)".  It was also a business decision, but
there are compelling technical reasons for us not to use Cygwin.

For instance, the Cygwin DLL is a sort of "consensual reality", if
you'll forgive the analogy.  The emulation involves communication
between Cygwin processes in some non-obvious ways (to me anyway).
One of the consequences is that Cygwin apps get real unhappy
when there's multiple copies of Cygwin installed, and there are folks
who already use Cygwin (obviously), so installing one's own
copy is fragile.  And there's vendors of third-party software
who ship copies of Cygwin in private directories, or heavily
modified, so you can't always rely on the installed copy.

Another reason is performance.  Not a big issue for GDB, but Cygwin
makes a pretty measurable dent in GCC compile times, or at least
it did the last time we did measurements.  That's another reason
we really needed to ship a MinGW toolchain, and having done so
there could be even more interoperability problems using it with
a Cygwin GDB.

-- 
Daniel Jacobowitz
CodeSourcery