The buildroot internal toolchain now adds a wrapper. When we use a
buildroot toolchain as an external toolchain, we want to bypass this
wrapper and call the compiler directly, for two reasons:
1. The options added by the wrapper are not necessarily appropriate
when it is reused as an external toolchain. For instance, ccache
may have been enabled while building the toolchain but not when
using it as an external toolchain.
2. Currently, the wrapper expects to reside in .../usr/bin, but when
used as an external toolchain it will be in .../ext-toolchain/bin.
Therefore, the wrapper can't find the real binary and sysroot
anymore.
To bypass the wrapper, we check for the existence of *.br_real files in
the external toolchain directory. If any such file exists, the wrapper
will add the .br_real suffix for all the wrapped files. Note that the
wrapper doesn't check if the *.br_real exists for each individual
wrapped file, it just assumes that all wrapped files have a
corresponding .br_real. This is currently true but that may change in
the future of course.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Add support for mips32r6 and mips64r6 target architecture variants
- Disable unsupported gcc versions
- Disable unsupported binutils versions
- Disable unsupported external toolchains
- Disable unsuported C libraries
- Add a hook in order to make glibc compile for MIPS R6.
[Thomas: slightly tweak the glibc hack explanation, to make it
hopefully clearer.]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Those two comments:
- are exactly the same
- have the same dependencies (except for arm/armeb)
So, make it a common comment. It will be useful to have that comment
when we introduce new Linaro toolchain versions.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The toolchain wrapper will be reused for the internal toolchain, so it
belongs in the toolchain directory. Also, the ext- prefix is removed
from it. The build commands are moved to a new toolchain-wrapper.mk.
The wrapper arguments that are also relevant for the internal toolchain
wrapper are moved to toolchain-wrapper.mk, the rest stays in
toolchain-external.mk.
While we're at it, move the building of the toolchain wrapper to the
build step of toolchain-external. There is no specific reason to do
this, other than that it fits better semantically. Also remove the
MESSAGE call, otherwise we'd see:
>>> toolchain-external undefined Building
>>> toolchain-external undefined Building toolchain wrapper
/usr/bin/gcc ...
Having an extra "Building toolchain wrapper' message is pointless.
The useless condition on $(BR2_TARGET_OPTIMIZATION) is removed. It was
always true because it wasn't qstrip'ped first, so clearly it works
without that condition as well.
Also rewrapped some comments and removed the 'external' reference.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For some external toolchain vendors the actual source code URL can be simply
derived from the binary file URL.
Here we obtain TOOLCHAIN_EXTERNAL_ACTUAL_SOURCE_TARBALL for all Mentor and
Linaro toolchains with a few $(subst) calls.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Trailing slashes are going to be declared illegal from FOO_SITE
variables.
But Buildroot internally generates such a variable when using a custom
external toolchain (i.e. BR2_TOOLCHAIN_EXTERNAL_CUSTOM). This is
because TOOLCHAIN_EXTERNAL_SITE is set to
$(dir $(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_URL))), and $(dir)
leaves a trailing slash.
Fix it using patsubst, just like linux and the bootloaders do.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
'echo -n' is not a POSIX construct (no flag support), we shoud use
'printf', especially in init script.
This patch was generated by the following command line:
git grep -l 'echo -n' -- `git ls-files | grep -v 'patch'` | xargs sed -i 's/echo -n/printf/'
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When ARCH is arm and the hard-floating-point option is on executables
expect to find the dynamic linker at /lib/ld-musl-armhf.so.1 and not
/lib/ld-musl-arm.so.1.
This patch adjusts the logic that creates the symbolic link from the
dynamic linker path to the musl C library (since musl has everything
built into a single file).
[Thomas: tweak the commit log.]
Signed-off-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Before this commit, the output of the toolchain-external build steps
looked like this (abbreviated for clarity):
>>> toolchain-external undefined Building
>>> toolchain-external undefined Installing to staging directory
>>> toolchain-external undefined Copying external toolchain sysroot to staging...
>>> toolchain-external undefined Building ext-toolchain wrapper
mkdir -p output/host/usr/bin; cd output/host/usr/bin; for i in ...
/usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='...
if test -f output/host/usr/bin/i686-pc-linux-gnu-gdb ; then mkdir -p ...
>>> toolchain-external undefined Fixing libtool files
>>> toolchain-external undefined Installing to target
>>> toolchain-external undefined Copying external toolchain libraries to target...
if test -e output/target/lib/ld-uClibc.so.1; then ln -sf ld-uClibc.so.1 output/target/lib/ld-uClibc.so.0 ; fi
if test -e output/target/lib/ld64-uClibc.so.1; then ln -sf ld64-uClibc.so.1 output/target/lib/ld64-uClibc.so.0 ; fi
All the long lines with conditions and loops in them are not usefull,
so put $(Q) in front of them. The line with mkdir can better be split
on a separate line so the cd stands out more. There are two redundant
semicolons that can be removed. The installation of gdbinit could
use an extra message so the user can see what is going on.
After this commit, the toolchain-external build steps look like this:
>>> toolchain-external undefined Building
>>> toolchain-external undefined Installing to staging directory
>>> toolchain-external undefined Copying external toolchain sysroot to staging...
>>> toolchain-external undefined Building ext-toolchain wrapper
/usr/bin/gcc -O2 -Ioutput/host/usr/include -DBR_SYSROOT='...
>>> toolchain-external undefined Installing gdbinit
>>> toolchain-external undefined Fixing libtool files
>>> toolchain-external undefined Installing to target
>>> toolchain-external undefined Copying external toolchain libraries to target...
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit c68c365d29 ("toolchain-external:
remove CS sh2 toolchains") removed the definitions of the
BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_SH2A_201103 and
BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_SH2A_201009, but did not actually
remove the code that was using those options.
So this commit removes the parts of the code that are currently dead
due to this: the definition of the prefix of those toolchains, the
hashes, and the URLs.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit wires up the gcc version dependency mechanism in the
external toolchain backend. To do so, it:
* Changes the definition of all pre-defined external toolchain
profiles to select the appropriate BR2_TOOLCHAIN_GCC_AT_LEAST_*
option.
* For custom external toolchains, provides a visible Config.in
"choice" to select the gcc version used in the external toolchain.
* Adds a new check_gcc_version function, that verifies that the real
gcc version found in the external toolchain matches the one
declared in the Buildroot configuration.
[Thomas: use better sed expression proposed by Yann E. Morin, which
works with more cases.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Before commit 5715d2dcf4, the external
toolchain wrapper would not pass its own march/mcpu/mtune flags to the real
compiler if at least one of them was passed on the wrapper command-line.
The mentioned commit intended to remove the passing of an mtune parameter
coming from Buildroot, which was always empty after some other refactoring,
but the changes have the side-effect that march/mcpu is now also passed when
mtune is already given on the command-line. In that case, only mtune should
be passed to the real compiler.
Restore part of the original toolchain wrapper code to check the presence of
mtune on the command-line.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit 34f95bf9db (toolchain-external: fix support of uClibc-ng toolchains,
2015-07-13) added the missing ld-uClibc.so.1 dynamic linker symlink that
binaries expect when linked with uClibc-ng. However on 64bit targets the
linker is called ld64-uClibc.so.1. Handle that case as well.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The uClibc-ng dynamic loader is called ld-uClibc.so.1, but gcc is not
patched specifically for uClibc-ng, so it continues to generate
binaries that expect the dynamic loader to be named ld-uClibc.so.0,
like with the original uClibc.
Therefore, when a uClibc-ng toolchain is used as an external
toolchain, we need to create an additional symbolic link to make
uClibc-ng systems work properly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The toolchain from the Cavium Networks Octeon SDK provides a sysroot
with library directories lib32, lib32-fp, lib64 and lib64-fp. The -fp
variants are used for processors with hardware floating point unit, such
as the Octeon III variants.
When specifying -march=octeon3 in BR2_TARGET_OPTIMIZATION, the toolchain
will use lib32-fp, but currently Buildroot does not accept that pattern.
This patch improves the matching by accepting lib(32|64)?([^/]*)? as lib
directory name.
Signed-off-by: Bai Yingjie <byj.tea@gmail.com>
[ThomasDS: update commit message]
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[Thomas: add comment above the function being modified to illustrate
the various cases we try to handle.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Like we do for the internal musl backend. We still see a large number of
build failures with musl, so warn users about it.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since 1.1.6, the mips softfloat toolchains are merged into the mips
toolchain using multilib. Our external toolchain infrastructure copies
the correct version to the target depending on the BR2_SOFT_FLOAT
option.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add hashes for all musl toolchains, including the ones that we
currently don't support (arm hf, sh4, x86_64-x32).
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For Linaro toolchains, a special post install staging hook is used to
create two symlinks needed for the dynamic loader to find the
libraries. However, the way the link is created prevents a 'make
toolchain-external-reinstall' from succeeding, because the symlink
already exists and points to a directory:
ln -sf . /home/thomas/projets/outputs/training/target/lib/arm-linux-gnueabihf
ln: '/home/thomas/projets/outputs/training/target/lib/arm-linux-gnueabihf/.': cannot overwrite directory
This commit adjust the hook to pass the '-n' option so that the link
name is treated as a normal file if it is a symbolic link to a
directory.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This uClibc toolchain does not provide an appropriate uClibc
configuration for Buildroot: missing IPv6, missing nsl stub, missing
program invocation, etc. Therefore, we mark it as broken, waiting for
a new upstream release of a new toolchain.
We keep around the toolchain-external Synopsys code anyway, since it
will most likely be identical for the new toolchain version. However,
we remove all the quirks that were introduced to start work around
issues related to this toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We will *always* be missing a hash file for custom external toolchains
that are downloaded.
So, just ignore that failure.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The 1.1.6 version of musl-cross fixes the two issues that had been
preventing versions after 1.1.1 being used by buildroot, namely:
- sysroot is enabled again
- kernel headers are included again
Signed-off-by: Will Wagner <will_wagner@carallon.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Remove BR2_INET_IPV6 select for predefined external toolchains.
Remove the (non)IPv6 option prompt since it's now mandatory.
And force the toolchain check now that internal uclibc is always built
with IPv6 support and external non-IPv6 toolchains are disallowed.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Normally we'd deprecate them, but:
1) They don't support IPv6 and it's being removed so it makes no sense.
2) They're based on uClibc 0.9.30-ish which is very old and surely has
package build breakage all over it.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It's required in some 32-bit architectures for the extended (64-bit)
atomic operations, like __sync_add_and_fetch_8.
These arches are at least: i386, mips & mipsel.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
There's no need for toolchains or the user to declare largefile support
since it's now mandatory.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With this change we add pre-built external toolachins for DesignWare ARC
cores. All currently existed flavours are supported:
* ARC 700 and ARC HS cores
* Little- and big-endian configurations
These pre-built tools are built with build scripts available here
(https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/tree/arc-2014.12)
and correspond to arc-2014.12 release of sources.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
The computation of TOOLCHAIN_EXTERNAL_BIN has a special case for
Blackfin, where it's set to
$(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/$(TOOLCHAIN_EXTERNAL_PREFIX)/bin
instead of $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/bin for other
architectures.
However, this is actually only true for Analog Devices pre-built
toolchains. Other Blackfin external toolchains (such as ones built by
Buildroot) do not have this special organization.
Therefore, in order to make those non-ADI Blackfin toolchains work, we
need to change the condition from BR2_bfin to testing specifically for
the ADI toolchains.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The recommended form is without the trailing slash. Buildroot will add a slash
between FOO_SITE and FOO_SOURCE as appropriate.
Reported-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add a new option BR2_GCC_ENABLE_LTO that builds gcc and binutils with
LTO support.
Individual packages still have to enable LTO explicitly by passing '-flto' to
GCC, which passes it on to the linker. This option does not add that flag
globally. Some packages detect if the compiler supports LTO and enable the flag
if it does.
To support LTO, ar and ranlib must be called with an argument which triggers the
usage of the LTO plugin. Since GCC doesn't call these tools itself, it instead
provides wrappers for ar and ranlib that pass the LTO arguments. This way
existing Makefiles don't need to be changed for LTO support. However, these
wrappers are called <tuple>-gcc-ar which matches the pattern to link to the
buildroot wrapper in the external toolchain logic. So the external toolchain
logic is updated to provide the correct symlink.
[Thomas:
- Add a separate BR2_BINUTILS_ENABLE_LTO option to enable LTO
support in binutils. This is a blind option, selected by
BR2_GCC_ENABLE_LTO. It just avoids having binutils.mk poke
directly into gcc Config.in options.
- Remove the check on the AVR32 special gcc version, which we don't
support anymore.
- Adapt the help text of the LTO Config.in option to no longer
mention "Since version 4.5", since we only support gcc >= 4.5 in
Buildroot anyway.
- Fix typo in toolchain-external.mk comment.]
Signed-off-by: Peter Kümmel <syntheticpp@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This toolchain is AMD64-only so restrict it accordingly.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add support for AMD steamroller optimizations, available in gcc 4.8+ as
bdver3.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
These have been deprecated since 2014.02
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
External toolchain can also have been generated by Buildroot previously, as
the list that follows demonstrates. Rephrase the paragraph describing what an
external toolchain is as suggested by Thomas Petazzoni, to make it clearer.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Slightly reword a comment to no longer mention avr32.
This part dealing with sysroot detection will have to be reworked, now
that we got rid of avr32: we can now require a fully sysroot-aware
toolchain, i.e. at least gcc-4.4.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, all the installation work of the toolchain-external package
is done during the install-staging step. However, in order to be able
to properly collect the size added by each package to the target
filesystem, we need to make sure that toolchain-external installs its
files to $(TARGET_DIR) during the install-target step.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Jérôme Pouiller <jezz@sysmic.org>
Getting the hashes from upstream is not always possible:
- Mentor's Sourcery: seems to require an account
- TI's Arago: not able to locate the upstream.
- Linaro: only signatures
- Misc other toolchains.
So, all hashes were locally computed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Those toolchains are downloaded from Sourceforge, and are therefore
affected by the Sourcefoge download issues. Therefore, this commit
adds the hashes for those toolchain tarballs.
Fixes:
http://autobuild.buildroot.org/results/fa5/fa5e38246dddd661f1d674f3521d21297796bce3/
(and other similar issues)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since a while, the semantic of BR2_PREFER_STATIC_LIB has been changed
from "prefer static libraries when possible" to "use only static
libraries". The former semantic didn't make much sense, since the user
had absolutely no control/idea of which package would use static
libraries, and which packages would not. Therefore, for quite some
time, we have been starting to enforce that BR2_PREFER_STATIC_LIB
should really build everything with static libraries.
As a consequence, this patch renames BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS, and adjust the Config.in option accordingly.
This also helps preparing the addition of other options to select
shared, shared+static or just static.
Note that we have verified that this commit can be reproduced by
simply doing a global rename of BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS plus adding BR2_PREFER_STATIC_LIB to Config.in.legacy.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The CodeSourcery toolchains have a very interesting feature: they warn
the user when an unsafe header or library path is used, i.e a path
that will lead host headers or libraries to leak into the build.
This commit adds a similar functionality into our external toolchain
wrapper, so that it can be used with all external toolchains, and can
also be tuned as needed. By default, the external toolchain wrapper
now gives warnings such as:
arm-linux-gcc: WARNING: unsafe header/library path used in cross-compilation: '-I /usr/foo'
arm-linux-gcc: WARNING: unsafe header/library path used in cross-compilation: '-L /usr/bleh'
but the compilation continues successfully. One can then easily grep
in his build log to search for occurences of this message.
Optionally, if BR_COMPILER_PARANOID_UNSAFE_PATH is defined in the
environment to a non empty value, the external wrapper will instead
error out and abort the compilation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Tested-by: Romain Naour <romain.naour@openwide.fr>
- Fix the help message for CodeSourcery MIPS toolchains
- Add a hash file
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some crazy folks use MIPS machines as build machines. ;-)
On MIPS, the only acceptable hash-style is 'sysv', because the MIPS ABI
defines that the GOT ordering to be the same as the symbols ordering,
while GNU hash requires symbols to be sorted by their hash.
Looking at binutils' code, it seems that only MIPS suffers from that
limitation.
Currently, we force the toolchain wrapper to be linked with both hash
styles, which breaks on MIPS.
So, fix that by singling out MIPS, and use sysv in that case, and both
otherwise.
Reported-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bump the ARM, ARMeb and AArch64 Linaro toolchains from 14.08 to
14.09. We can't bump to 14.10, because they completely changed the
toolchains and they are now completely broken: they switched from
Crosstool-NG to a new build tool to generate the toolchain, and now
the sysroot handling is completely borked.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the BR2_GCC_TARGET_TUNE value is always empty now, there is no
longer a point in using it in the external toolchain logic.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Refactor the toolchain-external Config.in file to use the
BR2_ARM_CPU_ARM*. All of the changes are purely mechanical, except for
the Arago ARMv5 toolchain: it had a 'depends on BR2_GCC_TARGET_ARCH !=
"armv5t"', but armv5t was not a possible value for
BR2_GCC_TARGET_ARCH. Since the toolchain is ARMv5TE, the only ARM
architectures we need to exclude are ARMv4 and ARMv4T.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 2d312b7b61 had a typo
"." instead of "_" in BR2_TOOLCHAIN_HEADERS_AT_LEAST_3.17.
This made selecting 3.17 as custom external headers version
impossible.
Signed-off-by: Karoly Kasza <kaszak@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Buildroot coding style defines one space around make assignments and
does not align the assignment symbols.
This patch does a bulk fix of offending packages. The package
infrastructures (or more in general assignments to calculated variable
names, like $(2)_FOO) are not touched.
Alignment of line continuation characters (\) is kept as-is.
The sed command used to do this replacement is:
find * -name "*.mk" | xargs sed -i \
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*$#\1 \2#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\]\+\)$#\1 \2 \3#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\ \t]\+\s*\\\)\s*$#\1 \2 \3#'
-e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\(\s*\\\)#\1 \2\3#'
Brief explanation of this command:
^\([A-Z0-9a-z_]\+\) a regular variable at the beginning of the line
\([?:+]\?=\) any assignment character =, :=, ?=, +=
\([^\\]\+\) any string not containing a line continuation
\([^\\ \t]\+\s*\\\) string, optional whitespace, followed by a
line continuation character
\(\s*\\\) optional whitespace, followed by a line
continuation character
Hence, the first subexpression handles empty assignments, the second
handles regular assignments, the third handles regular assignments with
line continuation, and the fourth empty assignments with line
continuation.
This expression was tested on following test text: (initial tab not
included)
FOO = spaces before
FOO = spaces before and after
FOO = tab before
FOO = tab and spaces before
FOO = tab after
FOO = tab and spaces after
FOO = spaces and tab after
FOO = \
FOO = bar \
FOO = bar space \
FOO = \
GENIMAGE_DEPENDENCIES = host-pkgconf libconfuse
FOO += spaces before
FOO ?= spaces before and after
FOO :=
FOO =
FOO =
FOO =
FOO =
$(MAKE1) CROSS_COMPILE=$(TARGET_CROSS) -C
AT91BOOTSTRAP3_DEFCONFIG = \
AXEL_DISABLE_I18N=--i18n=0
After this bulk change, following manual fixups were done:
- fix line continuation alignment in cegui06 and spice (the sed
expression leaves the number of whitespace between the value and line
continuation character intact, but the whitespace before that could have
changed, causing misalignment.
- qt5base was reverted, as this package uses extensive alignment which
actually makes the code more readable.
Finally, the end result was manually reviewed.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Yann E. Morin <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This new toolchain release fixes a number of issues found with the previous
one. In particular, the issues with fallocate64, prlimit64 and the
ill-installed linux headers seem to be fixed now.
Therefore, there's not need to sanitize the headers for this toolchain and some
packages should now build fine (e.g. fio).
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The 2014R1 toolchain is provided in two flavours by Analog Devices:
one based on gcc 4.3.x, which is considered stable, and one based on
gcc 4.5.x, considered experimental. In commit
5a65b8e185 ("toolchain-external: add ADI
Blackfin 2014R1 toolchain, remove 2012R1") both variants were added.
However, after some testing in the autobuilders, and discussion with
the Analog Devices folks, it turns out that the experimental version
of the toolchain is too experimental. It causes numerous build
failures, and the Analog Devices folks clearly say that it's an early
release and that they expect quite a few problems to show up.
Therefore, this commit removes the experimental flavor and keeps only
the stable variant. Note that the removal/renaming of the Config.in
options is not a problem, since those options were added after the
2014.05 release.
Fixes:
http://autobuild.buildroot.org/results/2a9/2a9d9c332a206fdb46bc8ba022c74d23082a6312/http://autobuild.buildroot.org/results/e1c/e1ce0c1cdd0139208dddaa8f2441ab0e3ab2385e/http://autobuild.buildroot.org/results/993/993aca3f4719afaa4b37524f9136fb8cdc53a066/
and more.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
However, this toolchain is only usable for e500v2 with the SPE ABI.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
And while we're at it, factorize the definition of the musl version,
since it's common to the definition of the tarball names for the
various supported architectures.
[Peter: Adjust Config.in info to match new version]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit adds support for two ADI Blackfin toolchains: the 'stable'
2014R1 based on gcc 4.3, and the 'experimental' 2014R1 based on gcc
4.5.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
For some reason, there is no ARMeb toolchain available in the 2014.05
Linaro release.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The major changes are: switch to gcc 4.9 instead of 4.8, and switch to
glibc 2.19 instead of glibc 2.18.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Linaro toolchains are released so frequently (every month) that it
doesn't make much sense to support 3 consecutive versions. So, like we
do for ARM big-endian, let's support only one version at a time.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Linaro toolchains are released so frequently (every month) that it
doesn't make much sense to support 3 consecutive versions. So, like we
do for ARM big-endian, let's support only one version at a time.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
When getting the sysroot used for the kernel headers version check,
passing TOOLCHAIN_EXTERNAL_CFLAGS causes a problem when used with
multilib toolchains, where only the main sysroot has the header files,
and the other sysroots only have the libraries.
Since the kernel headers version used is normally the same for all
sysroots, this commit solves this problem by removing the
TOOLCHAIN_EXTERNAL_CFLAGS argument when calling
toolchain_find_sysroot, so that it returns the main sysroot, in which
<linux/version.h> can be found for the kernel headers version check.
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since the introduction of the kernel headers Config.in options, the
external toolchain logic had a check for custom external toolchains to
verify that the kernel headers version entered by the user matches the
one of the toolchain. However, this check was not made for non-custom
external toolchains (i.e the built-in profiles, such as Linaro,
CodeSourcery and al.), making the assumption that the Buildroot
developers will do the right selection.
However, it is quite nice when bumping external toolchains to have
this automatic kernel headers version check, to ensure we select the
appropriate kernel headers version.
Therefore, this commit makes the kernel headers version check
applicable to non-custom external toolchains.
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Thomas: fix BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_15 to select
BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_14 and not itself.]
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As reported by William Welch <bvwelch@gmail.com>, the Musl external
toolchain provided by the musl-cross project is only Microblaze
big-endian. In fact, Musl seems to only support the big endian variant
of the Microblaze architecture, with the microblaze-* tuple.
This commit makes sure the Musl pre-built external toolchain provided
by musl-cross can only be selected for a big-endian Microblaze
configuration.
Reported-by: William Welch <bvwelch@gmail.com>
Cc: William Welch <bvwelch@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit cd32da8f79
("toolchain-external: add Linaro ARM big endian toolchain") a mistake
was made, probably due to a rebase conflict that was incorrectly solved:
the call to the post install staging hook that creates the necessary
symbolic links for a root filesystem based on Linaro 2014.02 to work
was removed.
This commit reinstates this call, which should fix the problem
observed by Maxime Hadjinlian while using Linaro 2014.02.
Reported-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit adds ten toolchains based on the musl C library that are
publicly available from the musl-cross project.
[Peter: fix ppc prefix, only for classic ABI]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit slightly improves the external toolchain backend, and the
gdb build logic to create a file named
$(STAGING_DIR)/usr/share/buildroot/gdbinit which can be used as a
gdbinit file using gdb -x option. This allows gdb to automatically use
the proper sysroot to find libraries.
The initial insight for this patch comes from the report of Oded
Hanson <OHanson@xsightsys.com>, who found an issue with the Eclipse
Buildroot plugin, which was setting a solib-path in gdb, but not a
sysroot. Setting a solib-path was enough to find shared libraries, but
not the dynamic linker. And since Eclipse doesn't allow to set the
sysroot in any other way than giving a gdbinit file, it makes sense to
have Buildroot generate a gdbinit file (which can be used in other
situations than Eclipse).
To achieve this, this commit introduces a gen_gdbinit_file helper in
toolchain/helpers.mk, and uses it for the internal toolchain and
external toolchain backends.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[ThomasDS: minor updates in commit message]
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Linaro has started to release ARM big endian toolchains, so we
integrate this toolchain in the external toolchain logic of
Buildroot. Since ARM big endian is probably going to be a lot more
uncommon than ARM little endian, we will only support one version at a
time of this toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The information "To use this toolchain, you must disable soft float
usage." which was visible in the help text of Linaro toolchains is no
longer useful, since those toolchains are only visible when the ARM
EABIhf ABI is selected, which by design is not compatible with
soft-float.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The Nios-II Sourcery external toolchain (the only Nios-II we currently
support) exports broken kernel headers. In particular, these kernels should
be exported using the "headers_install" rule which applies a set of fixes
on the kernel headers so they are suitable for userspace usage.
In order to fix this, add a post-install hook to perform the header fixes
ourselves. The result is equivalent to apply the "headers_install" rule.
Fixes:
http://autobuild.buildroot.net/results/c32/c32ad4bac5f651502e551f7733f702afaa0e742a/
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Old toolchains, with old gcc that do not support -print-sysroot, break the
kernel-headers version check script: it fails to find the sysroot of the
toolchain, and thus ends up including the host's linux/version.h.
Most of the time, this will break early, since the host's kernel headers
will not match the toolchain settings.
But it can happen that the check is succesful, although the configuration
of the toolchain is wrong:
- the custom toolchain has kernel headers vX.Y
- the user selected vX.Z (Z!=Y)
- the host has headers vX.Y
In this case, the check passes OK, but the build of some packages later on
will break (which is exactly what those _AT_LEAST_XXX options were added to
avoid).
Fix that by passing the sysroot to the check script, instead of the cross
compiler.
We get the sysroot as thus:
- for custom toolchains, we use the macro toolchain_find_sysroot. We can
do that, because we already have a complete sysroot with libc.a at that
time.
- for internal toolchain using a custom kernel headers version, we just
use $(STAGING_DIR). We can't use the macro as for custom toolchains
above, because at the time we install the kernel headers, we do not yet
have a complete sysroot with a libc.a. But we can just use
$(STAGING_DIR), since we're only interested in the kernel headers.
For all other types of toolchains, we already have the _AT_LEAST_XXX options
properly set, so we need not add a check in this case.
Fixes:
http://autobuild.buildroot.net/results/f33/f331a6eff0b0b93c73af52db3a6b43e4e598577e/http://autobuild.buildroot.net/results/a57/a5797c025bec50c10efdcff74945aab4021d05e4/
[...]
[Thanks to Thomas for pointing out the toolchain_find_sysroot macro!]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Like ARM ones, the Linaro AArch64 toolchains expect libraries in
/lib/aarch64-linux-gnu and /usr/lib/aarch64-linux-gnu, but Buildroot
always installs them in /lib and /usr/lib. Therefore, this commit adds
the appropriate symbolic links, just like we're already doing for
Linaro ARM toolchains.
Reported-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On x86, the symbolic link ld-musl-<ARCH>.so.1 to libc.so must be
ld-musl-i386.so.1 in all cases, but $(ARCH) in Buildroot might be
i386, i486, i586, i686, etc. depending on the specific x86 variants
being selected.
This commit fixes that by creating a MUSL_ARCH variable set to i386 on
x86, and to $(ARCH) on other architectures.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The user-facing variables should be prefixed with BR2_, not BR_.
Also quote the variable in the manual.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Ensure the kernel headers version used in the custom external toolchain,
or the manually-specified kernel headers version, matches exactly the one
selected by the user.
We do not care about the patch-level, since headers are not supposed to
change between patchlevels. This applies only to kernels >= 3.0, but
those are actually the ones we do care about; we treat all 2.6.x kernels
as being a single version, since we do not support any 2.6 kernels for
packages with kernel-dependant features.
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>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Select the appropriate BR2_TOOLCHAIN_HEADERS_AT_LEAST_XXX options for the
external, custom toolchain backend.
We try to be conservative here, and default to kernel headers 2.6.x.
[Thomas: remove duplicated depends on BR2_TOOLCHAIN_EXTERNAL_CUSTOM,
since the choice is already inside a if BR2_TOOLCHAIN_EXTERNAL_CUSTOM
... endif block.]
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>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Select the appropriate BR2_TOOLCHAIN_HEADERS_AT_LEAST_XXX options for the
external, pre-defined toolchains.
Also annotate those toolchain with older-than-3.0 headers.
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>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As our architecture support expands to a number of architectures that
do not implement NPTL threading, and the number of packages that
depend on NPTL specific features, it has become necessary to be able
to know whether the toolchain has NPTL support or not.
This commit adds a new BR2_TOOLCHAIN_HAS_THREADS_NPTL hidden Config.in
option that allows packages to know whether NPTL is available or not.
This hidden option is:
* Automatically enabled when glibc/eglibc or musl toolchains are
used, either internal or external.
* Automatically enabled when an internal uClibc toolchain with NPTL
support is configured. It is left disabled otherwise for internal
uClibc toolchains.
* Configured according to a visible Config.in option for custom
external uClibc toolchains.
[Peter: factor _EXTERNAL_HAS_THREADS in single if as suggested by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit makes the dependency from the target toolchain explicit.
This way we can buid from command line a package that use
inner-generic-package right after the configuration phase, example:
make clean <package-name>
Also remove TARGETS_ALL because the only purpose was to add toolchain
dependency so it's superseded by this commit.
To prevent circular dependency add the new variable
<pkgname>_ADD_TOOLCHAIN_DEPENDENCY to avoid adding the toolchain
dependency for toolchain packages.
This is also a step forward supporting top-level parallel make.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
AMD Jaguar ( https://en.wikipedia.org/wiki/Jaguar_%28microarchitecture%29 ) is
suddenly a popular architecture since it is used in the PS4 and the XBox One.
Many embedded systems are also likely to use it in the next years.
This patch adds support for GCC architecture-specific optimisations and
tuning for these CPUs.
These optimizations are available with GCC 4.8+.
Signed-off-by: Adrien Beraud <adrien.beraud@savoirfairelinux.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently ld-linux-armhf.so.* is added to external libs when
using an EABIhf toolchain, but this naming is not used by uClibc.
Fix by adding a check for glibc.
Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In order to keep better track of when a feature got deprecated, and hence
when it can be removed, a new set of symbols BR2_DEPRECATED_SINCE_xxxx_xx is
introduced. These symbols are automatically selected when BR2_DEPRECATED is
selected, and thus are transparent to the user.
A deprecated feature will no longer depend on BR2_DEPRECATED directly, but
rather on the appropriate BR2_DEPRECATED_SINCE_xxxx_xx. If that symbol does
not yet exist, it has to be created in Config.in.
When removing a deprecated feature, one should also check whether this was
the last feature using the BR2_DEPRECATED_SINCE_xxxx_xx symbol, in which
case the latter can be removed from Config.in.
A followup patch will make sure the overview is added to the list of
deprecated features in the manual, so that a buildroot core developer can
easily determine which features to remove in a given development cycle.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In our wrapper, we forcibly add the -march=, -mcpu= and-mtune= flags
to the actual compiler, this in an attempt to always generate correct
and optimised code for the target.
But in some cases, the caller knows better than we do, and passes its
own set, or subset of those flags. In this case, some may conflict with
the ones we pass. The most prominent offender being the Linux kernel.
For example, on the ARM Raspberry Pi, the Linux kernel will set the
-march=armv6 flag and no -mcpu= flag, but we pass -mcpu=arm1176jzf-s,
which conflicts:
drivers/scsi/scsi_trace.c:1:0: warning: switch -mcpu=arm1176jzf-s
conflicts with -march=armv6 switch
(and so for all the files the kernel compiles, pretty messy)
(note: arm1176jzf-s is not an armv6, it is an armv6zk. Yeah...)
To avoid this situation, we scan our commandline for any occurence of
the possibly conflicting flags. If none is found, then we add our owns.
If any is found, then we don't add any of our owns.
The idea behind this is that we trust the caller to know better than
we do what it is doing. Since the biggest, and sole so far, offender
is the Linux kernel, then this is a rather safe bet.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Xilinx Microblaze external toolchains that we had support for are
very old, and are causing a huge number of build issues. Thanks to
Spenser Gilliland, we now have support for Microblaze in the internal
toolchain backend, and the autobuilders have been using the internal
toolchain backend since then. Therefore, it's time to deprecate those
old and unusable external toolchains.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add Linaro ARM 2013.10 and Linaro ARM 2013.11, and remove Linaro ARM
2013.07 and Linaro ARM 2013.08.
The main change for those versions is the switch to eglibc 2.18.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit adds the support for the recently release Sourcery MIPS
2013.11 toolchain (gcc 4.8, gdb 7.6, glibc 2.18), and consequently
removes the support for the Sourcery MIPS 2012.03 toolchain.
While we're at it, also fix the incorrect help text related to the
MIPS64 multilib selection.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This commit adds the support for the recently release Sourcery ARM
2013.11 toolchain (gcc 4.8, gdb 7.6, glibc 2.18), and consequently
removes the support for the Sourcery ARM 2011.09 toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
(e)glibc doesn't support a fully statically linked userspace. Even a
basic program such as Busybox fails to do authentication due to glibc
loading some libraries dynamically. Therefore, we disable the
possibility of using a (e)glibc toolchain when
BR2_PREFER_STATIC_LIB=y.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch fixes the following whitespace problems in Config.in files:
- trailing whitespace
- spaces instead of tabs for indentation
- help text not indented with tab + 2 spaces
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Based on a suggestion from Peter, this commit factorizes the logic and
regular expressions that are used to find the sysroot and libdir for a
given compiler. It reduces a bit the duplication of code, and
centralizes the most bizarre part of this logic in one place.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: drop extra # as pointed out by Baruch Siach]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In a1d94aaa3a ('toolchain-external: add support for musl C
library'), we made the following change to the SYSROOT_DIR mangling
logic:
- SYSROOT_DIR=`echo $${LIBC_A_LOCATION} | sed -r -e 's:usr/lib(32|64)?/(.*/)?libc\.a::'` ; \
+ SYSROOT_DIR=`echo $${LIBC_A_LOCATION} | sed -r -e 's:(usr/)?lib(32|64)?/(.*/)?libc\.a::'` ; \
This was needed to accomodate for musl based toolchains that don't
have libc.a in usr/lib/..., but directory in lib/... Basically, the
change makes the usr/ at the beginning optional.
However, with the very permissive (.*) matching in the middle of the
path, the change above had an unexpected consequence: any path contain
'/lib' would be truncated before this lib. As an example, Peter
reported that his builds, running from /var/lib/buildbot/ were no
longer working because the SYSROOT_DIR was decided to be /var instead
of something like
/var/lib/buildbot/buildroot/output/host/opt/ext-toolchain/arm-linux-gnueabihf/libc/.
So, this commit changes (again!) this regexp by changing (.*) to
([^/]*), the idea being that it will match only *one* path
component. Note that this intermediate (.*) directory was added in
e6e60becb0 ('external-toolchain: add support for Linaro 2012.01') to
accomodate for Linaro toolchains that have a subdirectory in their
sysroot named after the target tuple:
$ ./output/host/opt/ext-toolchain/bin/arm-linux-gnueabihf-gcc -print-file-name=libc.a
/home/thomas/projets/buildroot/output/host/opt/ext-toolchain/bin/../arm-linux-gnueabihf/libc/usr/lib/arm-linux-gnueabihf/libc.a
In addition to this, this commit also makes sure that the change
making usr/ optional is properly reported on all the instances of this
regular expression.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For configurations using a toolchain that is preinstalled on
the host, <pkg>_SITE and <pkg>_SOURCE variables must be kept
empty to avoid downloading any toolchain package.
The actual implementation has been proposed by Thomas Petazzoni.
Signed-off-by: GONZALEZ Laurent <br2@gezedo.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As Samuel Martin noticed, libthread_db is not only needed when
cross-gdb+gdbserver is used, but also when the native gdb is used on
the target. As a consequence, this patch modifies the glibc package
and the external toolchain logic to ensure that libthread_db is copied
to the target either when the native gdb or gdbserver is enabled, by
relying on the BR2_PACKAGE_GDB option, which is enabled when native
gdb and/or gdbserver are enabled.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Maxime Ripard reported that the Linaro toolchains were not visible
when selecting a Cortex-A, but forgetting to set the EABI to
EABIhf. While this is expected, Buildroot should normally should a
comment in this case. However, the comment is only visible when the
selected ARM architecture is not ARMv7 *and* the EABI is not
EABIhf. Instead, make the comment visible when either the selected
architecture is not ARMv7 *or* when the selected EABI is not EABIhf.
While we're at it, reword the comment text so that it actually fits
within the limits of the menuconfig screen.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
In 11ec38b695 ("toolchain-external: fix Linaro ARM toolchain
support"), we fixed the support for Linaro EABIhf toolchains by adding
a /lib/arm-linux-gnueabihf -> /lib symbolic link. This is needed
because the dynamic loader looks for libraries in
/lib/arm-linux-gnueabihf rather than the usual /lib, but Buildroot
installs all libraries in /lib.
However, we forgot that the dynamic loader also loads libraries from
/usr/lib/arm-linux-gnueabihf rather than /usr/lib, so this patch fixes
that by adding the necessary symbolic link.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Previously, an external-toolchain on a mipsel/mips64el target
didn't select the appriopriate endianness but
it asked the user to set the correct CFLAGS on his/her own.
We fix this by appending "-EL" to the toolchain wrapper options
if the user has selected a mipsel/mips64el target.
[Thomas: remove unneeded test on BR2_ENDIAN, since mipsel and mips64el
are always little-endian, and add the corresponding big endian case.]
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some Config.in(.host) files have constructs like:
config FOO_VERSION
string
default "1.0" if FOO_1_0
default "2.0" if FOO_2_0
default $FOO_CUSTOM_VERSION if FOO_CUSTOM
The dollar sign here is not needed and confusing, so can be removed.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Angstrom toolchains available at
http://www.angstrom-distribution.org/toolchains/ are not usable as
external toolchains in Buildroot, because they are not pure toolchains
with just the C library, but instead complete SDKs with many
cross-compiled libraries (Gtk, Qt, glib, neon, sqlite, X.org, and many
more, approximately 200 MB of libraries).
Buildroot cannot use such toolchains, and while this is documented in
our manual, some users still try to do this. Today, one such user came
on the IRC channel, reporting a build problem, which we started
investigating, only to realize after a long time that he was using an
Angstrom toolchain.
To avoid this problem in the future, we explicitly check if the
toolchain is from Angstrom by looking at the vendor part of the tuple
exposed by the toolchain: as soon as it is
<something>-angstrom-<something-else>, we reject the toolchain with an
explanation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit fixes bug #6452 (eglibc from Linaro 2013.07 not copied to
target correctly) by:
* Copying only the relevant library loader to the target on ARMhf
(i.e ld-linux-armhf.so and not ld.so*). This is needed since Linaro
toolchains provide two library loaders, one ARMv7 hf, and one ARMv4
soft-float.
* Making sure a $(TARGET_DIR)/lib/arm-linux-gnueabihf/ symbolic link
to $(TARGET_DIR)/lib/ exists, since the dynamic loader of Linaro
toolchains expects libraries to be found in
$(TARGET_DIR)/lib/arm-linux-gnueabihf/.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit adds support for external toolchains based on the musl C
library, as available from http://www.musl-libc.org.
Note that the pre-built musl toolchains available from
http://musl.codu.org/ are not working for the moment, since they lack
sysroot support. However, this problem has been reported to the
maintainer, who has already added sysroot support in his scripts at
https://bitbucket.org/GregorR/musl-cross, and therefore the next
version of the pre-built toolchains should work with Buildroot
out-of-the-box. In the mean time, the musl-cross script must be used
to build the toolchain.
[Peter: reword comment]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Until now, the copy_toolchain_lib_root function took as argument the
base name of a library (e.g: libm.so), and was assuming that the usual
scheme libm.so.<x> being a symbolic link to the real library was used.
However, with musl based toolchains, the C library is named libc.so
directly, with no symbolic link at all. Therefore, this commit changes
the copy_toolchain_lib_root to move the responsibility of using a
wildcard or not after the library name the caller's responsibility.
So, all the existing LIB_EXTERNAL_LIBS values are modified to have a
.* at the end, so that the behavior is effectively unchanged.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The external toolchain code makes the assumption that all C libraries
have a ld*.so, libc.so, libcrypt.so, libdl.so, libgcc_s.so, libm.so,
libnsl.so, libresolv.so, libutil.so, and when thread support is
enabled, libpthread.so, etc.
However, this is not the case with the musl C library, which
integrates all the functionalities in a single libc.so file. In
preparation of the support of the musl library, we make the current
value of LIB_EXTERNAL_LIBS conditional to glibc or uClibc.
The addition of additional libraries through
BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS is kept outside the condition, at
the end.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit converts the 'toolchain-external' logic to the package
infrastructure.
The TOOLCHAIN_EXTERNAL_DIR variable (which points to where the
toolchain is located) is renamed to TOOLCHAIN_EXTERNAL_INSTALL_DIR,
because the former conflicts with the package infrastructure (which
defines the <pkg>_DIR variable for each package as pointing to its
build directory).
The new _EXTRA_DOWNLOADS mechanism is used for Blackfin toolchains.
The extract, configuration and installation steps are converted inside
the <pkg>_EXTRACT_CMDS, <pkg>_CONFIGURE_CMDS and
<pkg>_INSTALL_STAGING_CMDS.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The ext-tool.mk logic uses the TOOLCHAIN_EXTERNAL_PREFIX variable
unconditionally, even if the external toolchain is not used. Until now
this wasn't a problem since ext-tool.mk was only included when the
external toolchain backend was selected, but the next patches are
going to include this file unconditionally.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In case there are many arguments passed to the tools, the command line
can get very long, and difficult to parse visually.
For example, the Linux kernel passes a lot of arguments to gcc (at least
45, which gives 53 with our hard-coded args). Looking at such a command
line is daunting.
So, add the possibility to print each argument on its own line.
Also, enclose all args between single quotes, so the command line
can be safely copy-pasted without special chars (spaces, $) being
inrerpreted by the shell.
Add blurb about toolchain-wrapper to documentation at the same
time.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Acked-by: Luca Ceresoli <luca@lucaceresoli.net>
Tested-by: Luca Ceresoli <luca@lucaceresoli.net>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Update to the latest update for the 2013.05 toolchain
released on 11 September 2013.
https://sourcery.mentor.com/GNUToolchain/release2554
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit refactors how Stack Smashing Protection support is handled
in Buildroot:
*) It turns the BR2_TOOLCHAIN_BUILDROOT_USE_SSP option into an option
that only enables the SSP support in uClibc, when using the internal
toolchain backend.
*) It adds an hidden BR2_TOOLCHAIN_HAS_SSP option that gets enabled
when the toolchain has SSP support. Here we have the usual dance:
glibc/eglibc in internal/external backend always select this
option, in the case of uClibc/internal, it gets selected when
BR2_TOOLCHAIN_BUILDROOT_USE_SSP is enabled, in the case of
uClibc/external, there is a new configuration option that the user
must select (or not) depending on whether the toolchain has SSP
support.
*) It adds a new options BR2_ENABLE_SSP in the "Build options" menu,
to enable the usage of SSP support, by adding
-fstack-protector-all to the CFLAGS.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
In order to simplify determining the right extractor tool for a given
file type, this patch introduces a make function 'suitable-extractor'.
Its usage is $(call suitable-extractor,filename), and it returns the
path to the suitable extractor.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This commit adds the pre-built Sourcery CodeBench toolchains
currently available for the Nios-II architecture.
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Always link lib64 or lib32 to lib
* Only copy the architecture's lib directory to staging
* Also cleanup a couple of mkdirs (concerning some 'lib' directories).
Before this patch:
$ ls -ld host/usr/x86_64-buildroot-linux-gnu/sysroot/{,usr/}lib* target/{usr/,}lib*
drwxr-xr-x 2 samuel users 4.0K Aug 12 22:26 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib/
drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64/
drwxr-xr-x 5 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/
drwxr-xr-x 5 samuel users 4.0K Aug 12 22:27 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/
drwxr-xr-x 3 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/libexec/
drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 target/lib/
lrwxrwxrwx 1 samuel users 3 Aug 12 22:27 target/lib64 -> lib/
drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 target/usr/lib/
lrwxrwxrwx 1 samuel users 3 Aug 12 22:27 target/usr/lib64 -> lib/
$ find . -type l -xtype l # find broken symlinks
find: `./host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64/lib': Too many levels of symbolic links
find: `./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/lib': Too many levels of symbolic links
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_files.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_nis.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_compat.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_nisplus.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libutil.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libthread_db.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libcidn.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libcrypt.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libm.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_hesiod.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnsl.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/librt.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_db.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libanl.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libBrokenLocale.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_dns.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libresolv.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libdl.so
./target/etc/resolv.conf
./target/dev/log
After this patch:
$ ls -ld host/usr/x86_64-buildroot-linux-gnu/sysroot/{,usr/}lib* target/{usr/,}lib*
drwxr-xr-x 2 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib/
lrwxrwxrwx 1 samuel users 5 Aug 12 22:36 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64 -> lib/
drwxr-xr-x 5 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/
lrwxrwxrwx 1 samuel users 5 Aug 12 22:36 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64 -> lib/
drwxr-xr-x 3 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/libexec/
drwxr-xr-x 2 samuel users 4.0K Aug 12 22:36 target/lib/
lrwxrwxrwx 1 samuel users 3 Aug 12 22:36 target/lib64 -> lib/
drwxr-xr-x 2 samuel users 4.0K Aug 12 22:36 target/usr/lib/
lrwxrwxrwx 1 samuel users 3 Aug 12 22:36 target/usr/lib64 -> lib/
$ find . -type l -xtype l # find broken symlinks
./target/etc/resolv.conf
./target/dev/log
Fixes http://autobuild.buildroot.net/results/23fb6b1479d2b5906b72c9437b06ab4700ff246d/
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
n32 is not supported in Sourcery CodeBench toolchains.
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The external-toolchain infrastructure creates symbolic links for all
tools in the host directory. However, when buildroot builds its own
version of a cross debugger (BR2_PACKAGE_HOST_GDB), and the toolchain
also provides a cross debugger, there would be two symbolic links for
gdb in the host directory, which is confusing.
An example use case is where the external toolchain only provides a
64-bit gdbserver (e.g. Cavium Networks SDK) but the target is completely
32-bit (e.g. n32 ABI). In this case, using gdbserver on target requires
copying a bunch of 64-bit libraries to the target as well, just for gdb.
In this case, one can let buildroot build both gdbserver as cross-gdb
(both in 32-bit).
This patch modifies the symlink creation so that no gdb (or gdbtui)
symlink is created if buildroot is going to build a cross-gdb.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some toolchains, like the Cavium Networks' one, have lib32/ and lib64/
directories, while the standard lib/ is empty. To find libc.a, buildroot
currently only looks in lib/ and lib64/. This patch extends the search
to lib32/ as well.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The linux kernel and uboot specify -msoft-float in order to prevent floating
point code from being generated. This causes a conflict when -mfloat-abi=hard
or -mfloat-abi options are specified in the wrapper. This patch removes the
-mfloat-abi option from the options generated by the wrapper only when
-msoft-float, -mhard-float or -mfloat-abi are specified by the user.
[Peter: fix !BR_FLOAT_ABI case, simplify]
Signed-off-by: Spenser Gilliland <spenser@gillilanding.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
