Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3AB04184.1EEFE3F4@ece.gatech.edu>
Date: Wed, 14 Mar 2001 23:13:56 -0500
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christopher Faylor <cgf AT redhat DOT com>
CC: Andy Piper <andyp AT bea DOT com>, "James N. Potts" <jpmail AT limolink DOT com>,
        XEmacs NT List <xemacs-nt AT xemacs DOT org>, cygwin AT sources DOT redhat DOT com
Subject: Re: mingw32 build?
References: <4 DOT 3 DOT 2 DOT 7 DOT 2 DOT 20010312161841 DOT 00df9850 AT san-francisco DOT beasys DOT com> <4 DOT 3 DOT 2 DOT 7 DOT 2 DOT 20010314155309 DOT 00cc3ee0 AT san-francisco DOT beasys DOT com> <3AB017B2 DOT 2D87FCED AT ece DOT gatech DOT edu> <20010314203427 DOT A29500 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Christopher Faylor wrote:
> 
> [I hope I got the attribution right, here]
> At 05:26 PM 3/14/01 -0600, James N. Potts wrote:
> >I still ran into the cyggdbm problem, because configure finds the
> >cygnus version of gdbm and assumes it should use it.  Building with
> >"--with-database=no" fixed that.  Should this be the default for a
> >mingw32 build?
> >
> >Dunno.  Really the cygnus folks should ship mingw equivalents of all of
> >these and disambiguate them somehow from the cygnus ones.
> 
> Wow, I missed this somehow.  Usually my nose hair quivers uncontrollably when
> I detect someone suggesting that I should do more work for them.
> 
> Maybe this has been said already but mingw != cygwin.  It's a separate
> project.  We (i.e., I) do support limited mingw functionality in the
> compiler.  That's all that we do.  It's only good for Windows-specific
> compilations, AFAIK.

Chris, *I* was actually thinking about cygwin -mno-cygwin, not mingw
(although, I *think* that anything which benefits -mno-cygwin also
benefits mingw)  For instance, building a full *cygwin* version of
XEmacs (which includes the netinstall program == modified
cygwin-setup.exe), requires that netinstall.exe be built with cygwin
-mno-cygwin and links to -lz.  But, that zlib must be a non-cygwin
version (just like cygwin's setup.exe builds with its own internal copy
of zlib, which also must be compiled -mno-cygwin).  For now, I just
don't build netinstall when doing a cygwin build.

I can't speak for Andy (who has contributed a lot to the cygwin project
in the past -- his "usrlocal" tarball was *my* personal inspiration for
cygutils and all of my ports to cygwin-1.1.x), but if we're going to
support -mno-cygwin at all, an argument can be made that such support
should also include *some* libraries.

I don't know if I agree with that argument, but it is one worth hashing
out.

I am willing, if it is deemed appropriate, to *begin* providing
-mno-cygwin versions of *some* of my ported libraries, in the interests
of improving -mno-cygwin operation.  (I won't use the term 'mingw' --
that particular term seems to get under your skin :-)  As I said
earlier, that would be a LONG term project given my limited cycles, and
a few questions need to be answered, including the one you raise:  how
should such -mno-cygwin libs be separated from cygwin libs?

You've given a partial answer: they should not be included in the same
tarball as the cygwin libs.  And you've also raised a potential problem:
this behavior requires changes to setup.exe.  Thanks.

--Chuck

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple