delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2001/03/14/21:11:59

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
Delivered-To: fixup-cygwin AT cygwin DOT com@fixme
From: "Paul Garceau" <pgarceau AT qwest DOT net>
Organization: New Dawn Productions
To: cygwin AT cygwin DOT com
Date: Wed, 14 Mar 2001 18:09:42 -0800
Subject: Re: mingw32 build?
Reply-to: Paul Garceau <pgarceau AT qwest DOT net>
Message-ID: <3AAFB3E6.5162.1023538@localhost>
In-reply-to: <3AB017B2.2D87FCED@ece.gatech.edu>
X-mailer: Pegasus Mail for Win32 (v3.12c)


On 14 Mar 2001, at 20:15, the Illustrious Charles Wilson wrote:

> [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' ?

	yes.

> b) can statlibs and import libs generated from '(cygwin)gcc -mno-cygwin'
> work with mingw's gcc ?

	yes.
> 
> 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?

	As I recall these sorts of things should go to /usr/local/lib or 
/usr/local/<yourdir>.  Same would be true for .dlls if you want to use 
them (unless they are already defined in Win32 system folder).

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

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

	A number of these already exist under mingw distribution from 
http://www.mingw.org.  To get a better sense, you might want to 
download the binutils, gcc and runtime distributions from mingw site to 
determine what is and is not missing from Cygwin.

> 
> --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'.

	If you plan on doing a lot of mingw...it might be a better idea to 
simply download the Mingw distributions and deposit them in another 
directory on your (Win32) machine.  Much of what you are suggesting is 
already supported under Mingw distribution.  I am sure the folks 
working on Mingw would appreciate your input and likely welcome any 
patches you might suggest.

	As far as I know...Mingw has been added, in addition to Cygwin stuff, 
for those who desire to have the bash functionality for Mingw 
development (-mno-cygwin).

	For Cygwin, and I am assuming that Chris F. will gently correct me on 
this, Mingw is basically a "bonus", and it is supported only minimally 
for use in a Cygwin environment.  For full power Mingw builds, the 
Mingw distribution is your very best bet.  Cygwin environment allows 
mingw-gcc builds, it does not focus on them.  Thus the reason for the
 -mno-cygwin switch.

	Peace,

		Paul G.


Nothing real can be threatened.
    Nothing unreal exists.

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019