Mail Archives: cygwin/2002/01/10/19:26:11
Robert,
This all now makes a lot more sense to me. Those switch definitions have
confused me for a long time.
Thank you.
Jon
> -----Original Message-----
> From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com]On Behalf
> Of Robert Collins
> Sent: Thursday, January 10, 2002 2:28 PM
> To: Jon Leichter
> Cc: hschwentner AT yahoo DOT com; cygwin AT cygwin DOT com
> Subject: Re: Compiling apps to Mingw32 with cygwin
>
>
> ----- Original Message -----
> From: "Jon Leichter" <jon AT symas DOT com>
>
> > > No. Specify --host. The meaning is clearly documented in the
> autoconf
> > > 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
> binaries
> > 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
> completeness)
> 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
> that
> > the following is the appropriate set of switches for Cygwin-GCC to
> produce
> > 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
> exist.
>
> > --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
> compiler.
>
> > 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
> configure
> > 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
> around.
>
> See http://www.gnu.org/manual/autoconf/html_mono/autoconf.html#SEC117
>
> Rob
>
>
> --
> 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
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -