This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: gcc4: next release (Dave Korn we need you)
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