mingw32 build?

[Paul Garceau]

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