This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Compiling apps to Mingw32 with cygwin

Jon Leichter wrote:
> > -----Original Message-----
> > From: Earnie Boyd []
> > Sent: Thursday, January 10, 2002 2:31 PM
> > To: Jon Leichter
> > Cc:;
> > Subject: Re: Compiling apps to Mingw32 with cygwin
> >
> > Using `gcc -mno-cygwin' is switching the build environment to MinGW.  It
> > says use the headers in /usr/include/mingw instead of /usr/include and
> > to use the libraries in /usr/lib/mingw instead of the ones in /usr/lib.
> > Thus you're switching the build environment to MinGW.
> I already understand the implications of using the -mno-cygwin switch. To be
> more precise, -mno-cygwin does NOT tell GCC to use /usr/lib/mingw INSTEAD of
> the ones in /usr/lib. GCC, by generic default, will ALWAYS look in /usr/lib
> if it doesn't find the libraries it's looking for elsewhere. I recently
> posted a topic about this.
> The key to our lack of agreement is terminology, perhaps due to me. I
> understand that the -mno-cygwin switch causes Cygwin-GCC to generate MinGW
> binaries, but the switch is actually driven by the specs file. Cygwin-GCC is
> still a Cygwin binary. All other tools are still Cygwin binaries. I am not
> so sure that warrants the phrase "MinGW build environment". It seems to me
> that I'm still using a Cygwin build environment to generate MinGW binaries.

Not in the sense of what the "build environment" means to
AC_CANONICAL_SYSTEM, in those terms you are switching the build
environment.  If you were using a true cross build system for MinGW
then, yes you would be correct.  Since `gcc -mno-cygwin' isn't a true
cross build system then you're not correct.  The -mno-cygwin switch
changes the build environment from Cygwin to MinGW.

> In his last email on this topic, Robert Collins confirmed for me that it
> would be appropriate to specify --build=i686-pc-cygwin
> and --host=i686-pc-mingw32. (I've intentionally left --target out since it's
> not pertinent to this part of the discussion).

And if `gcc -mno-cygwin' where a true cross build system then yes it
apples.  However, it's not and the -mno-cygwin changes the build
environment to mingw32.

> > > The symlink approach (i.e. i386-pc-mingw32-gcc) might be appropriate for
> >
> > No, the poster has a wrapper script he named mgcc.  The symlink was for
> > binutils binaries.
> Actually, it was me (not the poster) that has an "mgcc" wrapper script. I
> was the one who suggested it.
> I still don't understand why I'd want to symlink the binutils binaries. I
> WANT the Cygwin binutils. They don't generate object code; they operate on
> it. The Cygwin binutils do a fine job (as Cygwin binaries) operating on
> MinGW binaries. I've never had a problem.

To emulate the cross build system.  Then you could safely use the
switches as you desire.

> > > latter versions of autoconf, but it does not work for earlier
> > versions. I
> > > contribute to the OpenLDAP project, specifically its MinGW
> > support. To build
> > > MinGW OpenLDAP, I've also got to build regex-0.12, gdbm-1.8.0, and
> > > libtool-1.4.2. As far as I can tell, none of the configure
> > scripts in these
> > > projects conform to the notion of looking for ${host}-gcc or any other
> > > ${host}-tool. In these projects, the solution I pointed out works
> > > flawlessly:
> > >
> > >         CC=mgcc ./configure --host=i686-pc-mingw32
> > >
> >
> > Not all contains AC_CANONICAL_SYSTEM.  Try ones that do.
> > E.G.: binutils, gcc.
> I understand that scripts written "properly" or in a standard
> manner will make "proper" use of --host, --build, and --target. My point is
> that not all projects do use it properly. It still requires that the project
> builder be aware. Without awareness, more and more people will post to
> mailing lists stating: "Hey, I used these switches as documented in
> Autoconf, and it didn't work right."

Which should mean that the maintainer of the package at least get a bug
fix report with patch so that the next release has it corrected.


Do You Yahoo!?
Get your free address at

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]