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>
