autoconf
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]