autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: removing the old build/host/target compatibility code (Was: current


From: Stewart Brodie
Subject: Re: removing the old build/host/target compatibility code (Was: current glibc vs debian sid)
Date: Thu, 24 Oct 2002 11:19:53 +0100
User-agent: Messenger-Pro/2.59beta2 (Newsbase/0.61b) (RISC-OS/4.00-Ursula002f)

In message <address@hidden>
          Akim Demaille <address@hidden> wrote:

> 
> | >>> "Akim" == Akim Demaille <address@hidden> writes:
> | [...]
> | 
> | Hosts and Cross-Compilation
> | ---------------------------
> | 
> |    Based on the experience of compiler writers, and after long public
> | debates, many aspects of the cross-compilation chain have changed:
> | 
> |    - the relationship between the build, host, and target architecture
> |      types,
> | 
> |    - the command line interface for specifying them to `configure',
> | 
> |    - the variables defined in `configure',
> | 
> |    - the enabling of cross-compilation mode.
> | 
> | 
> |    The relationship between build, host, and target have been cleaned
> | up: the chain of default is now simply: target defaults to host, host to
> | build, and build to the result of `config.guess'.  Nevertheless, in
> | order to ease the transition from 2.13 to 2.50, the following
> | transition scheme is implemented.  _Do not rely on it_, as it will be
> | completely disabled in a couple of releases (we cannot keep it, as it
> | proves to cause more problems than it cures).
> | 
> |    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.  Whenever you specify `--host', be sure
> | to specify `--build' too.

On the subject of overriding things, I have found that if I use CONFIG_SITE
to provide a set of defaults to force the build, host and target types to
what I want, that other things related to host, build & target setup do not
appear to work properly (at least in version 2.52) unless I set a whole raft
of other things which are really autoconf's internal state variables in order
to ensure that the cross-compiling was found and not the native one.  The
choice of compiler had already been made before I got the change to set
ac_tool_prefix.  Specifically, I found that I had to do (in full):


# Note that we prime the build, host and target types here!
# Users can override them though with --build, --host and --target
# The target is not overridden if host or target was specified
config_project_guess="config.guess"
config_project_sub="config.sub"
if test -z "$build_alias"; then
  # User did NOT specify a build alias - so default it
  build=`$config_project_guess`
  build_alias=$build
  ac_cv_build=$build
fi
if test -z "$host_alias$target_alias"; then
  target_alias=mipsel-linux
  target=`$config_project_sub $target_alias`
  ac_cv_target=$target
fi
if test -z "$host_alias"; then
  host_alias=mipsel-linux
  host=`$config_project_sub $host_alias`
  ac_cv_host=$host
fi
cross_compiling=maybe
ac_env_build_alias_set=${build_alias+set}
ac_env_build_alias_value=$build_alias
ac_cv_env_build_alias_set=${build_alias+set}
ac_cv_env_build_alias_value=$build_alias
ac_env_host_alias_set=${host_alias+set}
ac_env_host_alias_value=$host_alias
ac_cv_env_host_alias_set=${host_alias+set}
ac_cv_env_host_alias_value=$host_alias
ac_env_target_alias_set=${target_alias+set}
ac_env_target_alias_value=$target_alias
ac_cv_env_target_alias_set=${target_alias+set}
ac_cv_env_target_alias_value=$target_alias
# Ensure ac_tool_prefix is set early enough
test -n "$host_alias" && ac_tool_prefix=$host_alias-


It is entirely possible that this is being caused by the backward
compatibility stuff and that this would be fixed in 2.55.  If so, that's
great.  If not, has anybody else noticed this sort of thing in their builds?

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




reply via email to

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