Uppercase in cross-compiler name

[Yann Droneaud]

Hi,

When cross-compile, one have to use --host= and --build to enable
cross-compilation mode of ./configure.

The argument of --host is going to be used to recognize the "host
target" and as the prefix of the cross-compilation tools.

Let's say my toochain, vendor provided, is named "ARMv8-linux-gnu"
(just an exemple):
ARMv8-linux-gnu-as
ARMv8-linux-gnu-ar
ARMv8-linux-gnu-cpp
ARMv8-linux-gnu-gcc
ARMv8-linux-gnu-ld
...

Let's try to cross-compile a program with this example toolchain:

- With current autoconf and config.sub, using the name of the toolchain:

$ ./configure --host="ARMv8-linux-gnu" --build='x86_64-linux'

[unrelated output removed]

checking whether build environment is sane... yes
checking for ARMv8-linux-gnu-strip... ARMv8-linux-gnu-strip
checking build system type... x86_64-pc-linux-gnu
checking host system type... Invalid configuration
`ARMv8-linux-gnu': machine `ARMv8' not recognized
configure: error: /bin/sh ./config.sub ARMv8-linux-gnu failed

Architecture is not recognized. ./configure stop with error.

- With current autoconf and config.sub, using the canonical name of the
host system:

$ ./configure --host="armv8-linux-gnu" --build='x86_64-linux'

[unrelated output removed]

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for armv8-linux-gnu-strip... no
checking for strip... strip
configure: WARNING: using cross tools not prefixed with host triplet
checking build system type... x86_64-pc-linux-gnu
checking host system type... armv8-unknown-linux-gnu
checking for armv8-linux-gnu-gcc... no
checking for gcc... gcc
checking for armv8-linux-gnu-dumpbin... no
checking for armv8-linux-gnu-link... no
checking how to convert x86_64-pc-linux-gnu file names to
armv8-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain
format... func_convert_file_noop
checking for armv8-linux-gnu-objdump... no
checking for objdump... objdump
checking for armv8-linux-gnu-dlltool... no
checking for dlltool... no
checking for armv8-linux-gnu-ar... no
checking for ar... ar
checking for armv8-linux-gnu-strip... strip
checking for armv8-linux-gnu-ranlib... no
checking for ranlib... ranlib
checking for armv8-linux-gnu-gcc... gcc


./configure succeeded, but as one can see, it's not going to use the
correct toolchain (how can it ?).

- Following discussion on config-***@gnu.org

http://lists.gnu.org/archive/html/config-patches/2013-02/msg00002.html

let's try with the following patches on config.sub:

http://lists.gnu.org/archive/html/config-patches/2013-02/msg00000.html
http://lists.gnu.org/archive/html/config-patches/2013-02/msg00001.html

Yann Droneaud (2):
config.sub: use $name instead of $1
config.sub: be more liberal on input case: accept upper case name

$ ./configure --host="ARMv8-linux-gnu" --build='x86_64-linux'

[unrelated output removed]

checking whether build environment is sane... yes
checking for ARMv8-linux-gnu-strip... ARMv8-linux-gnu-strip
checking build system type... x86_64-pc-linux-gnu
checking host system type... armv8-unknown-linux-gnu
checking for ARMv8-linux-gnu-gcc... ARMv8-linux-gnu-gcc
checking whether the C compiler works... no
configure: error: in `/home/ydroneaud/foo':
configure: error: C compiler cannot create executables
See `config.log' for more details

It's working better: now the archicture is recognized, and the correct
toolchain is also used.

It's important to note, that, regardless the case, the host system type
as recognized by config.sub is not the exactly matching the toolchain
prefix, so there's no 1:1 relation on the host system type and the
toolchain name.

Allowing uppercase in --host might improve the compatibility of the GNU
build system against any toolchain or mixed environnement.

Regards.

[Yann Droneaud]

[Moving the discussion to ***@gnu.org]

Hi,

I've recently sent two patches against config.sub to
config-***@gnu.org

http://lists.gnu.org/archive/html/config-patches/2013-02/msg00000.html
http://lists.gnu.org/archive/html/config-patches/2013-02/msg00001.html

Yann Droneaud (2):
config.sub: use $name instead of $1
config.sub: be more liberal on input case: accept upper case name

I tried to explain the reasonning behind those patches in the following
thread:
http://lists.gnu.org/archive/html/config-patches/2013-02/msg00002.html

Those patches are to be used as part of a kind of a workaround for the
need to give a --build option when using --host option as part of a
cross-compilation.

When running ./configure --host=<triplet>, I'm getting

configure: WARNING: if you wanted to set the --build type, don't use
--host.
If a cross compiler is detected then cross compile mode will be used

It's explain in: 14.1 Specifying target triplets

"For historical reasons, whenever you specify `--host', be sure to
specify `--build too'; this will be fixed in the future. So, to enter
cross-compilation mode, use a command like this"

http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html#Specifying-Target-Triplets

So to create a "valid" --build argument, I was going to use
--build=`uname -p`-`uname -s` but its producing 'x86_64-Linux' which is
not recognized by config.sub. I was surprised by the behavor and made
patches to allow config.sub to recognize this string.

Even if I think config.sub should be more liberal in its input, autoconf
and ./configure script should probably be fixed to not require a --build
option when cross-compiling.

Could people on the list give some advice on this subject ?

Regards.

[Jan Engelhardt]

Post by Yann Droneaud
I tried to explain the reasonning behind those patches in the following
http://lists.gnu.org/archive/html/config-patches/2013-02/msg00002.html
Those patches are to be used as part of a kind of a workaround for the
need to give a --build option when using --host option as part of a
cross-compilation.
When running ./configure --host=<triplet>, I'm getting
configure: WARNING: if you wanted to set the --build type, don't use
--host.
If a cross compiler is detected then cross compile mode will be used
It's explain in: 14.1 Specifying target triplets
"For historical reasons, whenever you specify `--host', be sure to
specify `--build too'; this will be fixed in the future. So, to enter
cross-compilation mode, use a command like this"
http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html#Specifying-Target-Triplets
So to create a "valid" --build argument, I was going to use
--build=`uname -p`-`uname -s` but its producing 'x86_64-Linux' which is
not recognized by config.sub.

--build/--host/--target is not supposed to be fed any names besides those
in the config.sub "dictionary". Toolchain names that do not follow suit
are not usable, and that currently includes, for example, x32 support.

Post by Yann Droneaud
Even if I think config.sub should be more liberal in its input, autoconf
and ./configure script should probably be fixed to not require a --build
option when cross-compiling.

The --build flag is not required. If it were, you would get an ERROR
instead of a WARNING.

[Yann Droneaud]

Hi,

Post by Jan Engelhardt

Post by Yann Droneaud
So to create a "valid" --build argument, I was going to use
--build=`uname -p`-`uname -s` but its producing 'x86_64-Linux' which is
not recognized by config.sub.

--build/--host/--target is not supposed to be fed any names besides those
in the config.sub "dictionary". Toolchain names that do not follow suit
are not usable, and that currently includes, for example, x32 support.

Thank you for this clarification. I haven't found such claim in the
documentation, but I could have probably miss it.

Regards.

[Jan Engelhardt]

Post by Yann Droneaud

Post by Jan Engelhardt

Post by Yann Droneaud
So to create a "valid" --build argument, I was going to use
--build=`uname -p`-`uname -s` but its producing 'x86_64-Linux' which is
not recognized by config.sub.

--build/--host/--target is not supposed to be fed any names besides those
in the config.sub "dictionary". Toolchain names that do not follow suit
are not usable, and that currently includes, for example, x32 support.

Thank you for this clarification. I haven't found such claim in the
documentation

Look at it from the paranoid angle: there is no claim to the
contrary in the documentation either.

[Keith Marshall]

Post by Yann Droneaud
So to create a "valid" --build argument, I was going to use
--build=`uname -p`-`uname -s` but its producing 'x86_64-Linux' which is
not recognized by config.sub. I was surprised by the behavor and made
patches to allow config.sub to recognize this string.

Rather than running uname yourself, and piecing it together, could you
not let config.guess do that for you? That should generate a build
triplet which config.sub will recognise.

Post by Yann Droneaud
Even if I think config.sub should be more liberal in its input, autoconf
and ./configure script should probably be fixed to not require a --build
option when cross-compiling.

I find that irritating too. I've added this

# We need the canonical representation of the intended host platform
# identification triplet, from which to deduce the subsystem designator
# in distributed tarball names. (Note that we explicitly override any
# user specified "build_alias", because autoconf gets upset if "host"
# is specified without "build", and we need "host" if cross-compiling;
# all we need in this case is "host" != "build", and we don't really
# care what "build" is, but AC_CANONICAL_HOST gets very upset, when it
# calls ${srcdir}/build-aux/config.sub, if the user specifies a short
# form which it cannot resolve -- e.g. "--build=linux" will fail).
#
AC_CONFIG_AUX_DIR([build-aux])
build_alias=`${srcdir}/build-aux/config.guess`
AC_CANONICAL_HOST

fairly early in the configure.ac, (but after AC_INIT), for my current
MinGW project, to circumvent it.