Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3A91D56A.FA7C5FC9@ece.gatech.edu>
Date: Mon, 19 Feb 2001 21:24:42 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: Re: Has sys/stat.h changed
References: <VA DOT 00000664 DOT 00c93eee AT thesoftwaresource DOT com> <3A91984B DOT 8F87DBCB AT yahoo DOT com> <20010219174210 DOT A21171 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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