[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: autoconf, -rpath-link, and CC_FOR_BUILD
From: |
Keith Marshall |
Subject: |
Re: autoconf, -rpath-link, and CC_FOR_BUILD |
Date: |
Wed, 15 Apr 2009 12:49:57 +0000 |
User-agent: |
KMail/1.9.10 |
On Wednesday 15 April 2009 01:44:55 Eric Blake wrote:
> CC_FOR_BUILD is not an autoconf variable, but one that is
> typically supported by packages that need to support Canadian
> cross builds (such as gcc).
It isn't just Canadian builds that may need access to native tools,
even when building for a foreign *host*; (not necessarily `target',
in its autoconf sense). Even a humble package like groff, (GNU
troff), is a pig to build, when `build' != `host', (i.e. a regular
cross build), because it needs to *run* the binaries it builds, to
complete its own build.
> Since you appear to be using it to
> try and build an intermediate program that runs on the build
> machine, rather than building a final program running on the
> target, you are correct that you don't want it looking at the
> target's library.
Nor even the host's! (It's a good measure of how confusing the
whole build/host/target distinction is, when even autoconf's own
developers occasionally seem to get it mixed up).
Some time ago, I ported `man' to run with MinGW/MSYS; in the process
I autoconfiscated its naive, fundamentally non-portable configure
script: http://mingw.cvs.sourceforge.net/viewvc/mingw/man/
The build process starts out by creating some tools, which it
subsequently runs to facilitate the build. I wanted to build it
with `--build=i686-pc-linux --host=mingw32', but I couldn't have
the tools built with `CC = mingw32-gcc'; that part of the process
needs `CC = gcc', (the native linux compiler). I worked around
this by running a secondary configure, in a sub-directory, with
`host' overridden, (--build="" --host="", or not specified at all).
It's also imperative that this secondary configure does *not* share
a common cache file, with the primary.
In my case, I simply delegated the build of all the tools to the
sub-directory environment set up by the secondary configure; it is
also conceivable that this secondary configure could generate a
subsidiary script, which could then be sourced by the primary
configure, to assign appropriate values to CC_FOR_BUILD, etc.,
which could then be AC_SUBSTed in the primary.
--
Regards,
Keith.