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: <3AB017B2.2D87FCED@ece.gatech.edu>
Date: Wed, 14 Mar 2001 20:15:30 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Andy Piper <andyp AT bea DOT com>
CC: "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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[copied to the cygwin list]

Andy Piper wrote:
> 
> At 05:26 PM 3/14/01 -0600, James N. Potts wrote:
> >Oddly, this last patch (configure.in) was already in my checkout.  But the
> >configure script that was checked out with it was out of date.  One
> >"autoconf" later, and my configure worked.  Except....
> 
> Oops. Fixed now.
> 
> >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.

I maintain most of the graphics libs (and gdbm) for cygwin.  I've no
objection to also shipping native versions in the binary dists, but
that'll be a slow project since I have only limited cycles.

The dll's are already differentiated; each is named
"cyg<foo><version>.dll".  However, the import libraries and static libs
are not; also, I have never tried to build dll's using '(cygwin)gcc
-mno-cygwin'.  And, of course, '(cygwin)gcc -mno-cygwin' is a whole
'nother beast from "(mingw)gcc".  Can anyone tell me what issues there
are? 

a) can I build dll's using '(cygwin)gcc -mno-cygwin' ?
b) can statlibs and import libs generated from '(cygwin)gcc -mno-cygwin'
work with mingw's gcc ?

Also, where should mingw-specific import and static libs go, from a
cygwin standpoint? Certainly not /usr/lib.  /usr/lib/mingw ?
/usr/mingw/lib ?  What about mingw-specific dll's?

Since cygwin dll's are prefixed with 'cyg', should mingw dll's (for
these optional libraries) be prefixed with 'mgw' or something? (*)

Finally, what are the highest priorities for the libraries -- I assume
zlib is first since netinstall requires it, but then what?  gdbm? 
graphics?

--Chuck

(*) Note that current binutils support a '--dll-search-prefix' flag that
is used when hunting for dll's for direct (no import lib) linking.  So,
mingw's spec file can specify '--dll-search-prefix=mgw' (or whatever)
and that will "turn on" direct-to-dll link searching, regardless of what
prefix is chosen for mingw dlls.  This behavior however has no relation
to the ordinary (and still preferred) use of importlibs/statlibs with
names following the pattern 'lib<foo>.dll.a' and 'lib<foo>.a'. 
Direct-to-dll linking without an import lib is only done if no import
lib or static lib is found for a given '-lfoo' specifier, but a
<prefix><foo>.dll IS found.

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