Re: Autoconf on new platforms

[Ralf Corsepius]

On Sun, 2003-07-20 at 16:17, Andreas Buening wrote:
> Ralf Corsepius wrote:
> > 
> > On Sat, 2003-07-19 at 13:50, Andreas Buening wrote:
> 
> [snip]
> 
> > > # we have memcpy()
> > > ac_cv_func_memcpy=yes
> > > # but we don't have bzero()
> > > ac_cv_func_bzero=no
> > This only works for native builds.
> 
> Why that?
Sorry, my answer was a bit sloppy.

The actual problem is: The default "config.site" is a configuration
table describing your native build-host. This config.site does not have
any relation to your cross-target.

Therefore, if cross compiling, you have to setup a custom, non-default
config.site and to convince configure scripts to use the right on.

Simply running "configure --host=<host>" will pickup your build-host's
config.site and will pickup values that describe your build-host, and
not your cross-target.

IMHO, this is a defect in autoconf, but what's actually behind this is
the question "what shall a config.site contain?":
1. build host settings?
2. target-host settings?

If 1. applies, config.site must not contain any "features"
(ac_cv_have_<some-header> ac_cv_have_<some-feature> etc.).
If 2. applies it must not contain any tool setting (eg. Paths to tools)

Another problem is autoconf performing some wild guesses on the location
of config.site (From an arbitrary configure script):

# Let the site file select an alternate cache file if it wants to.
# Prefer explicitly selected file to automatically selected ones.
if test -z "$CONFIG_SITE"; then
  if test "x$prefix" != xNONE; then
    CONFIG_SITE="$prefix/share/config.site $prefix/etc/config.site"
  else
    CONFIG_SITE="$ac_default_prefix/share/config.site
$ac_default_prefix/etc/config.site"
  fi
fi
for ac_site_file in $CONFIG_SITE; do
  if test -r "$ac_site_file"; then
    { echo "$as_me:$LINENO: loading site script $ac_site_file" >&5
echo "$as_me: loading site script $ac_site_file" >&6;}
    sed 's/^/| /' "$ac_site_file" >&5
    . "$ac_site_file"
  fi
done

With a "native style" cross configuration:
./configure CC=cross-compiler
=> The build-host native config.site will be picked up.

With a 'cross style' cross configuration:
./configure --host=cross-target --prefix=/usr \
--exec-prefix=/usr/cross-target
=> The build-host native config.site will be picked up.

Now imagine Canadian cross-configurations (more than one target),
similar to what many cross-toolchain components apply (eg. binutils,
gcc).

It depends on the details of how this Canadian cross compilation is
implemented, but the conventions applied by most toolchain
configurations will apply the build-host native config.site.

IMHO, the conclusion is: config.site is not suitable to encode a
cross-target's features.

Actually, I strongly recommend (Personal preference) not to use
config.site in general at all. It's error-prone, hard to maintain and
(IMSHO) desturbs more than it helps.

Ralf