From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnout Vandecappelle Date: Mon, 9 Nov 2015 23:01:34 +0100 Subject: [Buildroot] [PATCH] core: fix setting of HOSTARCH In-Reply-To: <1447095621-32080-1-git-send-email-yann.morin.1998@free.fr> References: <1447095621-32080-1-git-send-email-yann.morin.1998@free.fr> Message-ID: <564117BE.4050300@mind.be> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net On 09-11-15 20:00, Yann E. MORIN wrote: > Currently, we set HOSTARCH to the output of `uname -m`. This gives us > the architecture as seen by the running kernel. For example, we would > end up with 'x86_64' for a 64-bit kernel running on an x86_64 processor. > > We use that value to determine whether we can run some binary tools, > like our pre-configured external toolchains. > > However, one may be running a userland in a different bitness than that > of the running kernel. For example, one may run in a 32-bit chroot, even > though the kernel is running in 64-bit. > > Up until recently, this was not an issue because the pre-configured > external toolchains were all requiring an i386 (x86 in Buildroot > parlance). > > But since w eintroduced the latest Linaro toolchains, we now have > toolchains that require a 64-bit userland. > > So, when running on a 64-bit kernel, we believe those toolchains are > available, even when the user is running a 32-bit userland. This causes > build failures for our autobuilders, like so: > > http://autobuild.buildroot.org/results/9cd/9cdf10ec5b31144b2e03ea09cf128702339895b3/ > > with the following symptoms: > > >>> toolchain-external undefined Configuring > Cannot execute cross-compiler '/home/test/autobuild/instance-3/output/host/opt/ext-toolchain/bin/aarch64-linux-gnu-gcc' > > So, instead of relying on the output of `uname -r`, look for the host > gcc and extract the target it was configured to generate code for. > > Fixes: > http://autobuild.buildroot.org/results/9cd/9cdf10ec5b31144b2e03ea09cf128702339895b3/ (aarch64) > http://autobuild.buildroot.org/results/888/8889aa7d9fb48370e4760a6edbc6d3ae945f02f2/ (arm) > and many more... > > Besides fixing those issues, it will also allow us to add the 64-bit > variants of toolchains when they exist, like the upcoming Codescape > MTI and IMG toolchains for MIPS from Imagination Technologies. > > Signed-off-by: "Yann E. MORIN" Reviewed-by: Arnout Vandecappelle (Essensium/Mind) But see below. > Cc: Thomas Petazzoni > Cc: Vicente Olivert Riera > --- > Makefile | 34 +++++++++++++++++++++++++--------- > 1 file changed, 25 insertions(+), 9 deletions(-) > > diff --git a/Makefile b/Makefile > index 80c264f..4c7ddf5 100644 > --- a/Makefile > +++ b/Makefile > @@ -52,15 +52,31 @@ ifneq ($(firstword $(sort $(RUNNING_MAKE_VERSION) $(MIN_MAKE_VERSION))),$(MIN_MA > $(error You have make '$(RUNNING_MAKE_VERSION)' installed. GNU make >= $(MIN_MAKE_VERSION) is required) > endif > > -export HOSTARCH := $(shell uname -m | \ > - sed -e s/i.86/x86/ \ > - -e s/sun4u/sparc64/ \ > - -e s/arm.*/arm/ \ > - -e s/sa110/arm/ \ > - -e s/ppc64/powerpc64/ \ > - -e s/ppc/powerpc/ \ > - -e s/macppc/powerpc/\ > - -e s/sh.*/sh/) > +# Determine the userland we are running on. > +# > +# Note that, despite its name, we are not interested in the actual > +# architecture name. This is mostly used to determine whether some > +# of the binary tools (e.g. pre-built external toolchains) can run > +# on the current host. So we need to know if the userland we're > +# running on can actually run those toolchains. > +# > +# For example, a 64-bit prebuilt toolchain will not run on a 64-bit > +# kernel if the userland is 32-bit (e.g. in a chroot for example). > +# > +# So, we extract the first part of the tuple the host gcc was > +# configured to generate code for; we assume this is our userland. > +# > +export HOSTARCH := $(shell gcc -v 2>&1 | \ > + sed -e '/^Target: \([^-]*\).*/!d' \ > + -e 's//\1/' \ > + -e 's/i.86/x86/' \ > + -e 's/sun4u/sparc64/' \ > + -e 's/arm.*/arm/' \ > + -e 's/sa110/arm/' \ > + -e 's/ppc64/powerpc64/' \ > + -e 's/ppc/powerpc/' \ > + -e 's/macppc/powerpc/' \ > + -e 's/sh.*/sh/' ) Since what we get here already are gcc tuples, the de-mangling shouldn't be needed, right? Regards, Arnout > > # Parallel execution of this Makefile is disabled because it changes > # the packages building order, that can be a problem for two reasons: > -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF