m5101 is the -march option for GCC, but the real core name is M5150.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This is a microcontroller class (MCU) core which is not suitable for
running Linux.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The Ingenic XBurst is a MIPS32R2 microprocessor.
It has a bug in the FPU that can generate incorrect results in certain
cases. The problem shows up when you have several fused madd
instructions in sequence with dependant operands.
Using the -mno-fused-madd option prevents gcc from emitting these
instructions. This patch adds changes to the toolchain wrapper to use
that option.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ARCH_SUBDIR is computed based on the value of ARCH_SYSROOT_DIR and
SYSROOT_DIR. For nested toolchains ARCH_SYSROOT_DIR is a subdir of
SYSROOT_DIR, so a sed command like this one...
sed -r -e "s:^${SYSROOT_DIR}(.*)/$:\1:"
...basically removes the leading SYSROOT_DIR part from ARCH_SYSROOT_DIR.
But, for side-by-side sysroot toolchains ARCH_SYSROOT_DIR and
SYSROOT_DIR are at the same level, so the above sed command doesn't
make any effect.
This patch therefore improves the calculation of ARCH_SUBDIR to
clearly handle the three possible cases:
- There is a single sysroot, or the selected architecture sysroot is
the main one (i.e SYSROOT_DIR == ARCH_SYSROOT_DIR). In this case,
ARCH_SUBDIR is empty.
- There are side-by-side sysroots, such as
SYSROOT_DIR=.../sysroot/mips-r2-hard/ and
ARCH_SYSROOT_DIR=.../sysroot/mipsel-r2-hard/.
- The arch-sysroot is nested, such as SYSROOT_DIR=.../sysroot and
ARCH_SYSROOT_DIR=.../sysroot/armv4t/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
[Thomas: improve the logic to handle the SYSROOT_DIR==ARCH_SYSROOT_DIR
case.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
On some architectures (namely x86-64), glibc may provide a libmvec
library since glibc 2.22, which programs built with gcc OpenMP support
might get linked to.
In order for these programs to work on the target, we need to copy
this library to the target filesystem.
This commit takes care of this for the external toolchain
situation. Note that libraries listed in TOOLCHAIN_EXTERNAL_LIBS are
silently ignored if they don't exist. Therefore, we don't need to have
any condition on the architecture or glibc version.
For more details on libmvec, see
https://sourceware.org/glibc/wiki/libmvec.
Fixes bug #9111.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
toolchain-wrapper was not reinstalled. So rules toolchain-external-reinstall,
gcc-initial-reinstall, gcc-final-reinstall didn't work as expected.
In add, normalize variable name: s/TOOLCHAIN_BUILD_WRAPPER/TOOLCHAIN_WRAPPER_BUILD/
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This hook was needed by 1014.09 Linaro toolchains.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested with Qemu 2.6.1 and qemu_aarch64_virt_defconfig and with
HOSTARCH set to x86 in the Buildroot main Makefile.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This Linaro release provide a new toolchain archive for i686 hosts, so update our
old 2014.09.
Tested with Qemu qemu-2.4.1-11.fc23 and with HOSTARCH set to x86 in the Buildroot
main Makefile.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-march=m5101 support starts from GCC-6, so disable previous versions
when selecting this core.
Note that M5101 implies a MIPS R5 CPU, and some GCC versions are already
disabled for R5, so we don't need to disable those ones for M5101 as
well.
Also disable external toolchains that don't support this core.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
-march=m5100 support starts from GCC-6, so disable previous versions
when selecting this core.
Note that M5100 implies a MIPS R5 CPU, and some GCC versions are already
disabled for R5, so we don't need to disable those ones for M5100 as
well.
Also disable external toolchains that don't support this core.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
-march=interaptiv support starts from GCC-6, so disable previous
versions when selecting this core.
Also disable external toolchains that don't support this core.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Tested with Qemu 2.6.1 and qemu_aarch64_virt_defconfig.
As reported by Gustavo Zacarias, this defconfig is known to fail with qemu
versions lower than 2.6.0.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some packages, like libbsd, use -isystem flags to provide so-called
overrides to the system include files. In this particular case, this
is used in a .pc file, then used by antoher package; pkgconf does not
mangle this path; and eventually that other package ends up using
/usr/include/bsd to search for headers.
Our current toolchain wrapper is limited to looking for -I and -L, so
the paranoid check does not kick in.
Furthermore, as noticed by Arnout, there might be a bunch of other
so-unsafe options: -isysroot, -imultilib, -iquote, -idirafter, -iprefix,
-iwithprefix, -iwithprefixbefore; even -B and --sysroot are unsafe.
Extend the paranoid check to be able to check any arbitrary number of
potentially unsafe options:
- add a list of options to check for, each with their length,
- iterate over this list until we find a matching unsafe option.
Compared to previously, the list of options include -I and -L (which we
already had) extended with -idirafter, -iquote and -isystem, but leaving
all the others noticed by Arnout away, until we have a reason for
handling them.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Current, we only display the path that causes the paranoid failure. This
is sufficient, as we can fail only for -I and -L options, and it is thus
easy to infer from the path, which option is the culprit.
However, we're soon to add a new test for the -isystem option, and then
when a failure occurs, we would not know whether it was because of -I or
-isystem. Being able to differentiate both can be hugely useful to
track down the root cause for the unsafe path.
Add two new arguments to the check_unsafe_path() function: one with the
current-or-previous argument, one to specify whether it has the path in
it or not. Print that in the error message, instead of just the path.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit a0aa7e0e17 and reworks
the code to fix a major and potentially catastrophic bug when the
following conditions are met:
- The user has selected a "known toolchain profile", such as a Linaro
toolchain, a Sourcery CodeBench toolchain etc. People using "custom
toolchain profile" are not affected.
- The user has enabled BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y to
indicate that the toolchain is already locally available (as
opposed to having Buildroot download and extract the toolchain)
- The user has left BR2_TOOLCHAIN_EXTERNAL_PATH empty, because his
toolchain is directly available through the PATH environment
variable. When BR2_TOOLCHAIN_EXTERNAL_PATH is non-empty, Buildroot
will do something silly (remove the toolchain contents), but that
are limited to the toolchain itself.
When such conditions are met, Buildroot will run "rm -rf /*" due to
TOOLCHAIN_EXTERNAL_INSTALL_DIR being empty.
This bug does not exist in 2016.05, and appeared in 2016.08 due to
commit a0aa7e0e17.
Commit a0aa7e0e17 removed the assignment
of TOOLCHAIN_EXTERNAL_SOURCE and TOOLCHAIN_EXTERNAL_SITE to empty, as
part of a global cleanup to remove such assignments that supposedly
had become unneeded following a fix of the package infrastructure
(75630eba22: core: do not attempt
downloads with no _VERSION set).
However, this causes TOOLCHAIN_EXTERNAL_SOURCE to be non-empty even
for BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y configuration, with the
following consequences:
- Buildroot downloads the toolchain tarball (while we're saying the
toolchain is already available). Not dramatic, but clearly buggy.
- Buildroot registers a post-extract hook that moves the toolchain
from its extract directory (output/build/toolchain-external-.../ to
its final location in host/opt/ext-toolchain/). Before doing this,
it removes everything in TOOLCHAIN_EXTERNAL_INSTALL_DIR (which
should normally be host/opt/ext-toolchain/).
Another mistake that caused the bug is commit
b731dc7bfb ("toolchain-external: make
extraction idempotent"), which introduce the dangerous call "rm -rf
$(var)/*", which can be catastrophic if by mistake $(var) is
empty. Instead, this commit should have just used rm -rf $(var) to
remove the directory instead: it would have failed without consequences
if $(var) is empty, and the directory was anyway already re-created
right after with a mkdir.
To address this problem, we:
- Revert commit a0aa7e0e17, so that
_SOURCE and _SITE are empty in the pre-installed toolchain case.
- Rework the code to ensure that similar problems will no happen in the
future, by:
- Registering the TOOLCHAIN_EXTERNAL_MOVE hook only when
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y, since moving the toolchain is
only needed when Buildroot downloaded the toolchain.
- Introduce a variable TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR which
is the path in which Buildroot installs external toolchains when it
is in charge of downloading/extracting them. Then, the
TOOLCHAIN_EXTERNAL_MOVE hook is changed to use this variable, which
is guaranteed to be non-empty.
- Replace the removal of the directory contents $(var)/* by removing
the directory itself $(var). The directory was anyway already
re-created if needed afterwards. Thanks to doing this, if $(var)
ever becomes empty, we will do "rm -rf" which will fail and abort
the build, and not the catastrophic "rm -rf /*".
Reported-by: Mason <slash.tmp@free.fr>
Cc: Mason <slash.tmp@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Even though 4.8 is not released yet, some people may want to build a
system using the 4.8-rc kernel, and point to the kernel sources as the
kernel headers to use for the toolchain.
In order to make this possible, this commit adds support for specifying
4.8 as the kernel headers version, in both the internal and external
toolchain logic.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
[Thomas: remove support for 4.8 headers selection, and rework commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It's been deprecated for quite some time now.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The default Blackfin processor in Buildroot isn't supported by
gcc 6.1.0, so use bf532 as default. Disable any bf6xx processors
for internal toolchain users.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add support for mips64, which is available since musl 1.1.15.
Only gcc 6.x has required support for it. Tested variations of
little/big endian and hard/soft float.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Latest musl release supports ppc64 architecture (both big endian and
little endian), so this commit adds support for this.
Since musl implements the ELFv2 ABI for both big-endian and
little-endian PowerPC64, we have to force using this ABI on PowerPC64
big endian (normally elfv1 is the default).
Also, only gcc 6.x has the necessary changes to support musl on PowerPC
64, so we restrict the gcc version selection accordingly.
Tested with Qemu for big endian and little endian configurations.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: add comment about the ABI flag in gcc.mk, rework commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
musl provides neither sys/queue.h nor sys/cdefs.h. Those two headers are
however quite widely used in a lot of packages (though they should at
least not use cdefs.h which is only full of mostly-legacy macros, and
which is mostly an internal header of glibc and was never really meant to
be exposed to, and used by packages).
But we don't live in an ideal world, so a lot of packages break when
those two headers are missing.
We already took care of sys/queue.h with the netbsd-queue package. But
the need for cdefs.h is getting more and more pressing.
We rename the netbsd-queue package into musl-compat-headers, and we
make it install sys/queue.h (from NetBSD) and sys/cdefs.h (a minimalist
one we bundle in Buildroot). We can't use the cdefs.h from NetBSD
because it includes machine-dependent headers; instead we bundle a very
minimalistic one, that covers only what we need.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The options to purge locales and to generate locale data are currently
located in the toolchain menu. However, these options are not really
related to the toolchain per-se, they are more system-level
configuration options, much like the timezone selection option we
already have in the "System configuration" menu.
Therefore, it makes more sense to have the locale-related options in
the "System configuration" menu as well.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Our current list of locales to keep by default is "C en_US de fr". It
doesn't make much sense to keep "de" and "fr" more than any other
language. So let's keep only the "C" and "en_US" locales by default,
and leave it to the user to specify other locales to keep if needed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Our current default is to keep all locales installed in
/usr/share/locale/. However, in practice, those locales take up a
significant amount of space, and most users do not need
locales. Therefore, it makes more sense to default to purging locales,
in order to keep only a few useful ones rather than keeping them all.
It helps in providing a small filesystem size by default, and still
allows advanced users who really need locales to tune their
configuration.
As an example, a very basic system with just util-linux enabled (not
even Busybox) weights 11 MB, including 6.4 MB of locales. With this new
default, the generated system is only 4.2 MB.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The cairo package fails to build on some architectures:
BR2_TOOLCHAIN_HAS_LIBATOMIC is enabled, but libatomic is in fact not
available.
This happens because the gcc logic in libatomic/configure.tgt does not
recognize "uclinux" as a valid OS part of the target tuple, and
therefore it does not build libatomic.
The "uclinux" part of the tuple is used by Buildroot when
BR2_BINFMT_FLAT=y, so we make BR2_TOOLCHAIN_HAS_LIBATOMIC enabled only
if !BR2_BINFMT_FLAT.
It is worth mentioning that support for the uclinux tuple could most
likely very easily be added to gcc: it could rely on the generic
"posix" implementation of libatomic, which uses pthread locks,
available on all architectures where thread support is available.
Fixes:
[arm] http://autobuild.buildroot.net/results/3d8dc45e41a043d2c2c26bfb26c3617499fbe671
[m68k] http://autobuild.buildroot.net/results/318e01406e3e92eb589ee5b2231c671a4dbb6da4
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: adjust dependency after analysis of the gcc code.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As described at:
4520524ba0
this commit continues a series of updates of ARC tools.
This time we're updating tools to arc-2016.09-eng007 tag plus a
couple of fixes on top of it that will all make its way in the
next engineering build.
We hope this patch will cure most buildroot ARC failures as it
contains important fixes:
1) PIE fix. We have added PIE support to ARC toolchain at last.
So that should prevent breakage of many packages. As ARC now
supports PIE we remove ARC from BR2_TOOLCHAIN_SUPPORTS_PIE
exclusion in toolchain/Config.in file.
2) Assembler fix. This patch also have changes that fixes frequent
assembler failures, e.g.:
http://autobuild.buildroot.net/results/543/5430b902d900943a34c1888e7e410bd5df367bc2//
We still keep GDB as it is of arc-2016.03 release because there're some
issues we'd like to resolve before releasing it to wider audience.
So again note this is next engineering builds of arc-2016.09 series
and it might have all kinds of breakages, please don't use it for
production builds.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
[Thomas: remove uClibc PIE patch, since we have bumped uClibc in the
mean time, to a version that contains the PIE fix for ARC.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that we have introduced the support for ARM no-MMU in Buildroot,
we need to update the dependencies of the musl external toolchain. It
supports only MMU-capable ARM cores, so it must depend on BR2_USE_MMU,
at least for the ARM platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
ARM big-endian is different from ARMv4/5/6 and ARMv7. Big-endian on
ARMv4/5/6 is BE-32 while big-endian on ARMv7 is BE-8, which are not
compatible.
Therefore, the musl big endian toolchain that is built for ARMv4
cannot work for ARMv7, it can only work for ARMv4/5/6.
This commit updates the musl toolchain dependency accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
uClibc-ng does not support PIE for some architectures as
arc and m68k. It isn't implemented in the static linking case, too.
With musl toolchains you might have static PIE support with little
patching of gcc. Static linking for GNU libc isn't enabled in
buildroot. Fixup any package using special treatment of PIE.
(grep -ir pie package/*/*.mk)
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: use positive logic.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As proposed initialy by Matthew Fornero [1], commonize the creation of
symlinks from {/usr}/lib to {/usr}/lib/<tuple> for Linaro toolchains.
This symlinks are only required for old Linaro toolchains.
[1] http://patchwork.ozlabs.org/patch/624577
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Matthew Fornero <mfornero@mathworks.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With gcc 6.1.0 and binutils 2.26 internal bfin toolchain can be used. A
gcc patch is required, which was reported upstream.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
[Vincent: BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX also has fortran]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
