Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
From: "Dale Goudey" <goudey AT earthlink DOT net>
To: <cygwin AT sourceware DOT cygnus DOT com>
Subject: Re:New gcc/binutils available for testing (TRY 2) -- fixes
Date: Fri, 16 Jun 2000 08:51:31 -0700
Message-ID: <01bfd7aa$bd893040$50d2b3d1@deschutes>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3

>Dale Goudey wrote
>>2.  For true mingw support (is there such a thing?), you will need to
>>install the complete
>>     mingw header/library set and modify the specs file (see below).

Chris Faylor response
>The Cygwin release contains libraries and include files that are common
>to both mingw and cygwin.  The windows specific include files that are
>in /usr/include are the same files that are released in a mingw-only
>distribution.  Ditto, the lib files.
>The only things that I see that are not already in cygwin are a couple
>of include files (gmon.h, profil.h, and profile.h) and libraries
>(crt2.o, dllcrt2.o, and gcrt0.o).  This is only a relatively cursory
>search, but I believe that this is correct.
>If Mumit wants to add these to the cygwin release when he gets back,
>I'll let him make that call.

What I meant by "true mingw support" was that the -mno-cygwin flag will
guarantee that the compile/link will NOT NEED the cygwin library, not MAYBE
NOT NEED.  As implemented in the cygwin distribution, the compiler will
"see" all the headers specific to the cygwin libraries whether the software
developer intended that of not.  The software developer can accidentally use
cygwin-specific functions and the compiler will not complain or offer a
warning.  To prevent link-time problems, the developer needs to know what
header files shouldn't be used with the -mno-cygwin flag.

I have a need to develop code that uses cygwin.  I also have a need to
develop (different) code that does not.  I also don't want to waste time
tracking down what headers I can or can't use when I use -mno-cygwin.  My
configuration (slightly modified from standard as I described) allows me to
do this.  If it costs me a separate set of headers on my hard disk, well I
think I can afford that (I can't afford the time wasted tracking down
problems related to what is and what is not only in the cygwin library).

I hope that eventually the cygwin and mingw implementations will "play
together" in a robust way.  I know my configuration is not perfect, but it
helps me get my job done.

Hope this clears up what I am trying to do.

To Chris Faylor:
I really appreciate the availability of a toolset such as that provided by
the cygwin package, and I appreciate your contributions to the gcc/binutils
packages.  I happy that my configuration works for me even if it is not the
"standard cygwin" way of doing things.  Keep up the good work!

Regards,
Dale Goudey




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com