Re: Has sys/stat.h changed

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Christopher Faylor wrote:
> 
> I have a new distribution ready to go.  I was waiting to see if I got everything
> right but testing it on some internal guinea pigs.
> 
> Unfortunately, they don't use cygwin the way the rest of the net does.
> 
> A couple of questions:
> 
> 1) Was the defaulting to -mno-win32 a noble but doomed experiment?

noble.  Doomed?  I dunno -- see below.  However, it is
truth-in-advertising.  This may sound doctrinaire, but if the lack of a
-D_WIN32 breaks a cygwin-targetted/hosted build of an app, then that app
is not properly ported.  The *app* needs fixin', not gcc. IMNSHO.

> 2) If we want to stick with -mno-win32 as the default, should gcc
>    include /usr/include/w32api by default?  I really don't think that
>    it should but I don't look forward to submitting changes to
>    the stuff in sources.redhat.com that breaks as a result.

Well, I *want* to say no, for the same reasons as specified above.  But
that would mean that all cygwin apps that need to include windows.h &
friends have to explicitly state "-I/usr/include/w32api". 

How stable is that?  Is /usr/include/w32api the "home" of windows.h &
friends for all time?  What about in a few years -- will we have
"/usr/include/w64api" and be forced to update all of the apps again?

Note that "well, just use -mwin32" is not a good answer.  Imagine an app
that is ported to both native windows and cygwin.  If I use -mwin32
(e.g. -DWINNT -D_WIN32" + change search paths) then how do my app's
local #ifdef's figure out if I'm *really* native, or just
CYGWIN-but-using-windowsy-stuff?

IMO, my app should be very very careful about such things, and should do
stuff like:

#if defined(_WIN32) && !defined(__CYGWIN__)
  windows-native code
#elif defined(__CYGWIN__)
  cygwin-specific code, might contain windows-ish, non-posix stuff if
necessary
#end

or 

#if defined(_WIN32) || defined(__CYGWIN__)
  stuff that's valid for both native windows or cygwin, but not valid
for other platforms
#end

THEN, it wouldn't matter if you used -mwin32 or not.  On cygwin, it
would *just work*.  On windows (mingw, cygwin-mno-cygwin) it would *just
work*.  But that's dreamland.

I think that for those reasons, the question of "#define _WIN32 and/or
WINNT" is actually orthogonal to whether /usr/include/w[32|64]api should
be automatically included in the include search path.  I think that
-mno-win32 should be the default (to ease the porting of NEW apps to
cygwin) -- although this may cause some pain for improperly but
previously ported apps.  I further think that /usr/include/w32api should
be included in the search path (after /usr/include, of course)
regardless of -mno-win32/-mwin32; otherwise we're forcing the assumption
of a particular, and subject-to-change, directory structure on all the
other projects out there in GNU-land.
 
> 3) Does anyone run this release of gcc as a cross compiler?  Corinna
>    isn't able to do this but I'm not having any problems building it.
> 
> 4) Is anyone going to checkin a libstdc++.a into winsup/mingw so that I
>    can add this to the distribution?

No opinion/data for 3) or 4).

--Chuck