On Thursday 17 August 2006 6:50 pm, Michael Gerdau wrote:
> I have done some more work on this. Attached to this mail you'll find
> my current version of the build-script together with the patch to fix
> the bugs in math.h (as had been reported on the userlist) as well as
> config.log for the following 4 testcase:
Thanks, Michael. I've not had time for an in-depth study yet, but here
are some initial observations:
> I have run configure for runtime with the following options:
> 1) host=i686-pc-linux-gnu build=i686-pc-mingw32
> 2) host=i686-pc-mingw32 build=i686-pc-linux-gnu
> 3) host=i686-pc-mingw32 build=i686-pc-mingw32
> 4) host=i686-pc-linux-gnu build=i686-pc-linux-gnu
Ok, I think some clarification of the meanings of `build', `host' and
`target' would be helpful, as they relate to the building of our
this is *always* the platform on which you are running the build
process; since we are building on Linux, this is unequivocally going to
specify `linux', with the canonical form being `i686-pc-linux-gnu'.
this is a tricky one: it specifies the platform on which whatever we
are building is going to be run; for the cross-compiler itself, that's
also `i686-pc-linux-gnu', but when we get to the stage of building the
runtime support libraries to go with that cross-compiler, they must
contain code which will run on the `i686-pc-mingw32' host, so the `host'
specification should change to this, for the `runtime' and `w32api'
stages of the build.
this is probably the one which causes the most confusion; it is only
relevant when building a cross-compiler, and it specifies where the code
which is built by that cross-compiler itself will ultimately run; it
should not need to be specified at all, for the `runtime' or `w32api',
since these are already targetted to `i686-pc-mingw32' by a correct
Given these definitions, your case `4' is correct for building the
cross-compiler itself, with case `2' being correct for the `runtime' and
`w32api' components. Cases `1' and `3' would apply only if you were
running the build process itself on a Win32 box.
Note also, that cases `3' and `4' are *not* cross-compiling cases.
> target=i686-pc-mingw32 in all 4 cases.
As noted above, this is relevant only with case `4', when configuring the
cross-compiler. Normally, it wouldn't be required at all, when building
`runtime' or `w32api', but I think it's harmless to specify it anyway.
> For case 1 and 4 I have set CC=i686-pc-linux-gnu-gcc since otherwise
> it would use my native gcc for compiling.
This would also represent a native compiler, which is of course what you
want when building the cross-compiler itself, but not when you build the
`runtime' and `w32api' components, by which stage you should have
switched to `CC=i686-pc-mingw32-gcc', (assuming that the cross-compiler
is built with that name); but `configure' should be able to work that out
for itself, given the correct combination of `--build=i686-pc-linux-gnu'
and `--host=i686-pc-mingw32' specifications.
BTW, what you specify in `--host=...' is internally assigned, within
`configure', to a shell variable called `host_alias'. There is another
internal variable called `host', which may be set equal to `$host_alias',
or it may be translated to the canonical equivalent, if `configure.ac' or
`configure.in' specifies `AC_CANONICAL_HOST'. Regardless of how `host'
is defined, `configure' will always look for compilers and tools with
`$host_alias-' prefixed to their name, e.g. `CC=$host_alias-gcc', falling
back to the naked name, only if the qualified variant isn't found. Thus,
you should always specify `--host', if you need it at all, to correctly
identify the prefix you've used to name your own cross-compiler tool
chain: that may not necessarily be the full canonical host name, and
indeed, the default in our build script requires `--host=i586-mingw32',
and not `--host=i686-pc-mingw32'.
Hope to have more, when I've had a chance to examine your config.log
files in more detail. Since case `2' is the relevant one, I'll focus on
that, in the first instance.