This is the mail archive of the
cygwin-apps@sources.redhat.com
mailing list for the Cygwin project.
Re: Has sys/stat.h changed
- To: cygwin-apps at cygwin dot com
- Subject: Re: Has sys/stat.h changed
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- Date: Mon, 19 Feb 2001 21:24:42 -0500
- References: <VA.00000664.00c93eee@thesoftwaresource.com> <3A91984B.8F87DBCB@yahoo.com> <20010219174210.A21171@redhat.com>
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