This is the mail archive of the
mailing list for the Cygwin project.
RE: Compiling apps to Mingw32 with cygwin
- From: "Jon Leichter" <jon at symas dot com>
- To: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- Cc: <hschwentner at yahoo dot com>, <cygwin at cygwin dot com>
- Date: Thu, 10 Jan 2002 16:26:11 -0800
- Subject: RE: Compiling apps to Mingw32 with cygwin
This all now makes a lot more sense to me. Those switch definitions have
confused me for a long time.
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org]On Behalf
> Of Robert Collins
> Sent: Thursday, January 10, 2002 2:28 PM
> To: Jon Leichter
> Cc: email@example.com; firstname.lastname@example.org
> Subject: Re: Compiling apps to Mingw32 with cygwin
> ----- Original Message -----
> From: "Jon Leichter" <email@example.com>
> > > No. Specify --host. The meaning is clearly documented in the
> > > documentation.
> > > For clarity:
> > > build - what OS the compilation is running on..
> > > host - what OS the binaries created should run on.
> > > target - what OS the binaries created should target their output to.
> > Actually, I'm a little unclear. Are you saying that 'target' is for
> > that you build, which in themselves, generate other binaries? Would an
> > example of this be GCC?
> Yes. The way they are used is kinda cool. Imagine that you've got a new
> platform (say wince). It's got no gcc at the moment, and the c compiler
> you've got for it is brain-dead (can't host a two-stage gcc build). You
> do have a C library that should build for it.
> What you do is:
> build gcc+binutils with --build=here --host=here --target=wince
> and then build the C library for that platform. Place those libraries in
> an appropriate search location (ie /usr/local/lib/wince :})
> then you
> build gcc+binutils with --build=here --host=wince --target=wince
> and then you copy the resulting binaries to the target platform, and
> finally can build
> gcc as a native 3 step boot strap, to ensure everything is ok. i.e. (for
> build gcc+binutils with --build=wince --host=wince --target=wince
> > Would I still need to "properly" specify --target if
> > I wasn't building binaries that generated binaries? Would you then say
> > the following is the appropriate set of switches for Cygwin-GCC to
> > MinGW binaries:
> Target can be safely skipped if you know for sure that the package does
> not create platform specific output. I'm not saying 'binaries' here
> because there are other forms of platform specific output that may
> > --build=i686-pc-cygwin --host=i686-pc-mingw32 --target=i686-pc-mingw32
> Yes, that should work. GCC will look for a i686-pc-mingw32 cross
> > Can I leave out the --build switch? Will it get automatically
> resolved? Or
> Thats what I said :}. I was wrong (I've just rechecked).
> In theory I'm right, but for backward compatability, if you specify
> host, but not build, then build is set to host. This is (obviously)
> wrong and will eventually get removed. For now specify both build and
> host explicitly. (which is a bummer for cross- scripts (because the user
> must then know what build is, or the script must duplicate what
> config.guess and config.sub do.).
> > does that ALSO depend on how well configure.in was written? In the
> > scripts I've used, I have consistently seen the 'build' variables get
> > assigned the same values as the 'host' variables.
> You've seen broken scripts then. There may well be brain damaged scripts
> See http://www.gnu.org/manual/autoconf/html_mono/autoconf.html#SEC117
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ: http://cygwin.com/faq/
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html