Practically speaking, MIPS has three useful ABIs:
* o32 is for 32-bits CPUs, or 64-bit CPUs running only a 32-bit subset
of the instruction set.
* n32 is for 64-bits CPUs only. It has 32-bits pointers and long
integers.
* n64 is for 64-bits CPUs only. It has 64-bits pointers and long
integers.
See http://www.linux-mips.org/wiki/MIPS_ABI_History and
http://www.linux-mips.org/wiki/WhatsWrongWithO32N32N64 for more
details.
So, this commit reworks the Buildroot MIPS support by:
* Add separate mips64/mips64el top-level architectures.
* Renaming the n32 ABI option to BR2_MIPS_NABI32, for consistency
with BR2_MIPS_OABI32.
* Renaming the n64 ABI option to BR2_MIPS_NABI64, for consistency
with BR2_MIPS_OABI32.
* Make the n32 and n64 ABI selections select the BR2_ARCH_IS_64,
since those ABIs are valid on 64-bits CPUs only.
* Removing the o64 ABI, which is practicaly never used.
* Removing the "none" ABI, which really doesn't make sense.
* Introduce the mips64 and mips64el architecture names when a 64-bits
MIPS ABI is choosen. This will fix build issue like
http://autobuild.buildroot.org/results/9b8c5ea86c953a89e85e7b67e9221de41773f652/build-end.log
where gmp was confused by the fact of having a 32 bits architecture
(detected by the mips- architecture part of the tuple) but 64 bits
integer size when compiling.
* Adjust the uclibc.mk logic to support the new mips64/mips64el
architecture names, and take into account the renaming of the ABI
options.
This has been build tested by generating Buildroot toolchains and
compiling a few packages for MIPS o32, MIPS n32 and MIPS n64.
This work is originally based on prior work done by Gustavo Zacarias.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Introduced by 68973cca2 (adjust logic to support Linaro 2012.05)
Reported-by: R Zhong <rzhong@hotmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Commit ba92d6ef68 made hard float the
default when Cortex-A8 and Cortex-A9. The problem it was trying to fix
is that the newer Linaro toolchains (2012.05 and 2012.06) are
hard-float, so the default selection of soft-float enabled on ARM
doesn't work for those toolchains.
Unfortunately, not selecting soft-float causes problems with
the Crosstool-NG backend at the moment.
As an intermediate solution, make the soft float option disappear when
using external toolchain: the toolchain will decide by itself whether
to generate hard float or soft float code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of having two separate list of choices for select the target
architecture variant for i386 and x86_64, with many CPU choices
duplicated (because all modern x86 CPUs can be both used as i386 or
x86_64), merge them into a single list. In the x86_64 case, all the
x86 CPUs that do not support the 64 bits instruction set are hidden.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
All the defconfig files used by the autobuilders that use
pre-installed external toolchains are making the assumption that the
default for a custom external toolchain is "pre-installed". We keep
this default for now, since changing it breaks the autobuilders.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cortex-A8 and Cortex-A9 ARM cores are guaranteed to provide a hardware
floating point unit, so there's no reason to default to software
floating point for them.
More importantly, the newest Linaro toolchains are hard float
toolchains, so basically an user choosing those toolchains and leaving
the default option of software float would run in compilation issues.
So let's make hard float the default for Cortex-A8 and Cortex-A9.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The check_glibc function verifies that the C library of the external
toolchain is glibc. To do so, it verified that a file matching
ld-linux*.so.* or ld.so.* was found in the lib/ directory of the
toolchain's sysroot. However, with the Linaro 2012.05 toolchain, the
lib/ directory contains two links named ld-linux-armhf.so.3 and
ld-linux.so.3, which means that the first ld-linux*.so.* wildcard
expression expands to two files, which generates a syntax error for
the "test" program. We replace that with a more elaborate find+wc
combination to determine whether at least one matching file is
present.
The check_arm_abi function verifies the ABI of an ARM toolchain. For
EABI, it tested that the target name ends with eabi. However, with
Linaro 2012.05, the tuple is now arm-linux-gnueabihf (for hard float),
so we have to adjust the logic to accept this additional "hf"
specification in the tuple.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Line-up with changes from commit 3367d5ce77
"external-toolchain: run checks even on extracted toolchains"
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch adds the possibility to download a custom external
toolchain, in addition to the existing support of preinstalled custom
external toolchains.
With the modified configuration, the user is presented with the
following options:
- Toolchain type: Buildroot toolchain | External toolchain | Ct-ng toolchain
In case of External toolchain:
- Toolchain: the CodeSourcery toolchains | Custom toolchain
- Toolchain origin: Toolchain to be downloaded and installed | Pre-installed toolchain
In case of Toolchain to be downloaded, the user is presented with:
- Toolchain URL
In case of Pre-installed toolchain, the users sees:
- Toolchain Path
For CodeSourcery toolchains, the toolchain URL field is not used (the
URLs are directly coded in ext-tool.mk).
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fix the indentation of the external toolchain Config file, where tabs
and spaces are mixed as indentation even within the same block.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
MIPS EABI is a bare-metal ABI so remove it.
Also fix uClibc to really work with N32 ABI, which used the EABI knob
previously.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of providing two variables, make GNU_TARGET_NAME give the real
target name, and remove REAL_GNU_TARGET_NAME altogether.
Signed-off-by: Richard Braun <rbraun@sceen.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Block unsupported processors according to gcc version.
Also remove the comments since we now hide them according to this.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Bump default snapshot gcc version to 4.8-20120429 so that it is newer
than our latest supported version (4.7.0 release).
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Decimal floats were introduced circa gcc-4.2 or -4.3, and requires
the floating-point environement fenv.h in the C library.
The uClibc .config file used by crosstool-NG to build uClibc is the
same as used by the internal buildroot mechanism, and explcitly
disables fenv support.
The quick workaround is to simply disable decimal floats in all
crosstool-NG config files.
In the long run, it might be better to check this situation, and/or
add code and/or options in crosstool-NG to handle this (but it is
much more involved, and this workaround is sane).
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
SUPPORT_LIB_DIR would get resolved to the main buildroot directory for
external toolchains without C++ support, as:
- gcc -print-file-name=<nonexisting-file> returns <nonexisting-file>
- readlink -f <nonexisting-file> returns $PWD/<nonexisting-file>
So fix it by ensuring output of gcc -print-file-name actually exists
before using it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
