Re: building native tools in a cross-compile environment

[Stewart Brodie]

In message <address@hidden>
          Ralf Corsepius <address@hidden> wrote:

> Am Mit, 2002-06-19 um 04.36 schrieb Harlan Stenn:
> > I've been looking thru the docs and I I haven't found a way to do the
> > following.
> > 
> > I am using automake and autoconf.
> > 
> > I am assuming:
> > 
> > - "build" means the arch of the build machine
> > - "host" the arch of the place where built stuff gets run
> > 
> > autoconf detects build != host and sets up for a cross-compile.
> > 
> > This is a Good Thing, and CC=host_cpu-host_vendor-host_os-gcc when I am
> > cross-compiling.
> > 
> > However, I am coming across a case where the software package has some
> > tools that are designed to be used as part of the build process and
> > therefore need to use build-cc instead of host-cc.
> Welcome to the wonderful world of mixed-cross compilation :)
>  
> > So how do I tell automake that for some PROGRAMS it should use host-cc
> > instead of build-cc?
> This is an autoconf problem, not an automake one.
> 
> The short answer is: It currently is not possible without further
> tricks.
> 
> One way to accomplish this is to:
> 1. Separate each of such directories into separate config-subdirs.
> 2. Implement a toplevel configure-script to parse build/host/target and
> to setup build/host/target for each config-subdir individually.
> 
> One example of how I apply this approach can be found inside of the
> toplevel configure of RTEMS:
> ftp://ftp.oarcorp.com/pub/rtems/snapshots/rtems/ss-20020528/rtems-ss-20020528.tar.bz2

I cannot get to that site ... is the URL correct (or am I just being filtered
by my own company's firewall)?

> Another example using this approach is the toplevel configure script of
> the unified GNU-toolchain.
> 
> Another (IMO hackerish) approach would be to apply tricks with
> presetting CC inside of tools's config-subdirs. E.g. to pub something
> similar to this into the configure.acs of build-host-compiled
> config-subdirs:
> 
> CC=${CC_FOR_BUILD-$CC}
> AC_PATH_PROG

The workaround I use is to explicitly go into the subdirectory and execute
alocal, automake, autoconf, then configure.  I do that at the bottom of
configure.in just before calling AC_OUTPUT.  I use the options:

  --build=$build_alias --host=$build_alias --target=$host_alias

Of course, doing this I lose record of the final target :-(

IMHO, a neater solution would be to have a companion to AC_CONFIG_SUBDIRS for
configuring a 'native' sub-directory.   If the _AC_OUTPUT_SUBDIRS could put
some sub-directory-specific options into ac_sub_configure_args, for example
ac_sub_configure_extra_<subdirname>_args, then that would be sufficient. 
AC_CONFIG_NATIVE_SUBDIRS could then put the options I showed above into this
variable.  This would enable you to clear out any setting for CC for the
sub-directory too.

If AC_CONFIG_NATIVE_SUBDIRS took two parameters, namely the list of
subdirectories and the value of the extra arg string for all those
directories, this would provide a solution for the people wanting to pass
extra --enable and --disable options into sub-packages too (in which case a
different name might be an idea)

This would probably mean that _AC_OUTPUT_SUBDIRS would have to intercept any
--host --build & --target options in favour of things in _extra_ variables,
but otherwise should have no impact on existing scripts, AFAICT.


-- 
Stewart Brodie, Senior Software Engineer
Pace Micro Technology PLC
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom         WWW: http://www.pacemicro.com/