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: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Date: Mon, 19 Feb 2001 21:24:57 -0500 From: Christopher Faylor To: cygwin-apps AT cygwin DOT com Subject: Re: Has sys/stat.h changed Message-ID: <20010219212457.A23112@redhat.com> Reply-To: cygwin-apps AT cygwin DOT com Mail-Followup-To: cygwin-apps AT cygwin DOT com References: <3A91984B DOT 8F87DBCB AT yahoo DOT com> <20010219174210 DOT A21171 AT redhat DOT com> <3A91D56A DOT FA7C5FC9 AT ece DOT gatech DOT edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <3A91D56A.FA7C5FC9@ece.gatech.edu>; from cwilson@ece.gatech.edu on Mon, Feb 19, 2001 at 09:24:42PM -0500 On Mon, Feb 19, 2001 at 09:24:42PM -0500, Charles Wilson wrote: >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? Dunno. Good question. Maybe I should have just named the directory "windows" rather than "w32api". However, regardless, you'll have to update gcc anyway if it does change since gcc's default won't. Maybe it is easier to just update gcc rather than 27 different packages which include -I/usr/include/wNNapi, though. cgf