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

On 7/12/2010 8:02 AM, Corinna Vinschen wrote:
> On Jul 12 05:25, Yaakov S wrote:
>> On Mon, 2010-07-12 at 10:41 +0200, Corinna Vinschen wrote:
>>> You're missing number 4.  Cygwin and Mingw are targeting the same
>>> underlying "real" target, which is Windows. 

I wasn't actually "missing" it; I just considered this part of #2, but
didn't fully express it: "things that should be identical...out of
sync".  E.g. if it's all one OS, then all compilers should use identical
headers.  And, if they are (or should be) identical, then why not have a
single common location?

I understand that argument, but we're not sure they all really CAN be
identical (e.g. the 64bit libs vs. the 32bit ones; the possible issue
with mingw64 headers' provenance, etc).  So, if there might be SOME
differences, then...

It makes sense to me, then, that each toolchain should provide, in a
private area (e.g. sysroot), that version of the w32api libs and headers
with which it has been tested.  Rather than a hodge-podge where "these
two cross toolchains have their own custom w32api headers that they
share between them but separate copies of the w32api libs; /that/ one
has a custom w32api that isn't shared with anybody, but /this/ one
shares w32api with cygwin's gcc..." Ick.)

>>> 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.

I assume that you were not proposing to move the w32api headers from
/usr/include/w32api/ into /usr/include/ proper, nor the libs from
/usr/lib/w32api into /usr/lib proper, were you?

If the cross toolchains provide their own w32api (and mingw-runtime)
[or, for 64bit, "mingw64-crt-headers" and "mingw64-crt-lib"], then...the
only remaining user of our current w32api api package is cygwin's own
gcc (all versions).

And the only remaining user of our current mingw-runtime packages is
cygwin's gcc3 (and anything that might require /usr/bin/mingwm10.dll).

So, after all of the cross compilers are deployed, we might think about
what optimizations we could make with regards to how the
non-toolchain-sysroot-specific w32api and mingw-runtime packages
are...packaged.  (The answer may be: make no changes.)  But I don't want
to start that discussion too early, so let's table it for now.

>> 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.
> Yeah, everything comes with a price tag.

Yep.  I have to keep reminding people that #including <windows.h> will
cause _WIN32 to be defined, and that #ifdef _WIN32 does not, actually,
mean !CYGWIN...


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