gcc4: next release (Dave Korn we need you)

[Yaakov (Cygwin/X)]

On Mon, 2010-07-12 at 10:41 +0200, Corinna Vinschen wrote:
> That's something I'll doo as soon as we really intend to switch the
> Cygwin build to mingw64's w32api.  Right now, what I get from all the
> gory details, it's not that easy to keep mingw64's w32api headers and
> libs apart from the mingw headers and libs anyway.

No, it's not.

> You're missing number 4.  Cygwin and Mingw are targeting the same
> underlying "real" target, which is Windows.  Both systems use different
> approaches and both have their own set of libs and headers which only
> make sense in their own environment.  But underneath they both run on
> Windows.  For that reason my POV is that w32api is an intrinsic part of
> the system and that's why it belongs into /usr/include and /usr/lib.
> IMHO.

OTOH there are a number of packages out there that see <windows.h> in
the default include path and say, "Oh, this must be a Windows system!
Let's use winsock/GDI/etc."  which is often -- but not always --
incorrect on Cygwin.  w32api may not be limited to cross-compiling, but
having it in the default search path isn't always great either.

> If there's no way around it, I don't mind if we have multiple w32api,
> one for the system and one for each mingw cross compiler.  I don't
> mind the disk space.  I don't know beforehand which solution will
> result in more or less user confusion.  So just go ahead.

This will be much easier from the packaging perspective.

> As for the path issue, I'd prefer to get a layout which closely
> resembles the Fedora mingw filesystem layout as in
> http://fedoraproject.org/wiki/Packaging/MinGW#Filesystem_layout.

That is what I'm working with now.


Yaakov