

Other format: [Raw text]

Re: Compiling apps to Mingw32 with cygwin

Jon Leichter wrote:
> Earnie. Your comments seem to contradict each other. In your last email, it
> seems you are implying that "gcc -mno-cygwin" is NOT a cross-compile. And
> then you went on to explain how I could safely use the switches if I set
> symlinks to emulate a cross-compile. Which point of view do you support
> Earnie?

1) `gcc -mno-cygwin' is not a cross compile.
2) it is possible to emulate a cross build system using a scripted `gcc
-mno-cygwin' and symlinks.
3) `gcc -mno-cygwin' switches the build environment from Cygwin to

> It seems as though for the most part, you do not agree with Robert's point
> of view, i.e. that using "gcc -mno-cygwin" is NOT a cross-compile, that
> MinGW IS the build environment. Thus, you have implied that one invokes with
> the following (assuming configure script is up-to-date and well-written):
>                           --target=i686-pc-mingw32

> I believe that target would still be optional, since it will get the value
> of host. Agreed?
yes target is optional.  However, host and build are not because
config.guess would guess wrong.

> As we know (because Robert has verified), build WILL get the value of host
> with the lastest autoconf. In that respect, even build is optional. HOWEVER,
> since the intended future behavior is for build to be tested no matter what,
> then its specification WOULD be necessary.
Shrug, use it a you don't loose.  Don't use it and you might loose.

Specifying the System Type

scripts can make decisions based on a canonical name for the system
type, which has the form: `CPU-VENDOR-OS', where OS can be `SYSTEM' or

`config.guess', which infers the name using the `uname' command or
symbols predefined by the C preprocessor.

   Alternately, the user can specify the system type with command line
involved.  The options to specify them are(1):

     the type of system on which the package is being configured and

     the type of system on which the package will run.


   They all default to the result of running `config.guess', unless you
specify either `--build' or `--host'.  In this case, the default
becomes the system type you specified.  If you specify both, and
they're different, `configure' will enter cross compilation mode, so it
won't run any tests that require execution.

   Hint: if you mean to override the result of `config.guess', prefer
`--build' over `--host'.  In the future, `--host' will not override the
name of the build system type.  Also, if you specify `--host', but not
`--build', when `configure' performs the first compiler test it will
try to run an executable produced by the compiler.  If the execution
fails, it will enter cross-compilation mode.  Note, however, that it
won't guess the build-system type, since this may require running test
programs.  Moreover, by the time the compiler test is performed, it may
be too late to modify the build-system type: other tests may have
already been performed.  Therefore, whenever you specify `--host', be
sure to specify `--build' too.


will enter cross-compilation mode, but `configure' will fail if it
can't run the code generated by the specified compiler if you configure
as follows:

     ./configure CC=m68k-coff-gcc

   `configure' recognizes short aliases for many system types; for
example, `decstation' can be used instead of `mips-dec-ultrix4.2'.
`configure' runs a script called `config.sub' to canonicalize system
type aliases.


   (1) For backward compatibility, `configure' will accept a system
type as an option by itself.  Such an option will override the defaults
for build, host and target system types.  The following configure
statement will configure a cross toolchain that will run on
NetBSD/alpha but generate code for GNU Hurd/sparc, which is also the
build platform.

     ./configure --host=alpha-netbsd sparc-gnu


> Well we still have a problem. Since build and host ARE the same, then we're
> NOT doing a cross-compile, and configure will NOT look for ${host}-gcc or
> any other ${host}-tool. It would STILL be necessary to set CC appropriately.
> The original invocation that I had posted was:
>         $ env CC=mgcc ./configure --host=i686-pc-mingw32

If it works for you, use it.  It seems to be supported even if it's just
backward compatibility.

> You said this was wrong. To be consisent with future behavior, it seems that
> I must specify build. So if you're suggesting that I'm not cross-compiling,
> then it would be:
>         $ env CC=mgcc ./configure --host=i686-pc-mingw32 --build=i686-pc-mingw32

This is what I would do.

> Would you still say that setting CC above is wrong? If so, how will
> configure find the executable that invokes "gcc -mno-cygwin"?

No, you must set the CC yourself or modify the m4 code that searches for
a default compiler.  However, with autoconf-2.50 and greater it's
suggested that you do
  ./configure CC=mgcc --host=i686-pc-mingw32 --build=i686-pc-mingw32
as configure will store the CC variable in the config.status file.

> Also, if cross-compiling is wrong, then why would I ever want to define any
> ${host}-<tool> symlinks?

Cross compiling itself isn't wrong so I'm going to assume you mean `gcc
-mno-cygwin' isn't cross compiling.  So that you can emulate cross
compiling, i.e. --host=i686-pc-mingw32 --build=i686-pc-cygwin will cause
a proper configure to search for i686-pc-mingw32-gcc.

For clarification, I was thinking that --host without --build would
cause the build environment to be guessed.  I must have been confused
with future plans for autoconf.  There was discussion about this on the
autoconf list months ago if you care to research the autoconf archives. 
Hmm... Here's what the info file says:

     Compute the canonical host-system type variable, `host', and its
     three individual parts `host_cpu', `host_vendor', and `host_os'.

     If `--host' was specified, then `host' is the canonicalization of
     `host_alias' by `config.sub', otherwise it defaults to `build'.

     For temporary backward-compatibility, when `--host' is specified
     but `--build' isn't, the build system will be assumed to be the
     same as `--host', and `build_alias' will be set to that value.
     Eventually, this historically incorrect behavior will go away.


Do You Yahoo!?
Get your free address at

Unsubscribe info:
Bug reporting:
