The current SSP handling is incomplete.
First we need to build uClibc with SSP support for a complete
"experience".
Second, it doesn't hurt to add -fstack-protector-all to the
CFLAGS/CXXFLAGS since most users would expect buildroot to do this
rather than adding the flags themselves.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
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>
If BR_DEBUG_WRAPPER is set in the envirnment, dump the actual command
being exec()uted, to ease debugging issues with the wrapper.
[Peter: adjust code style and output format to be cut'n'paste compatible]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
With modern shells, we can simply do test using the "$(...)" = "value"
form. This commit gets rid of the x$(...) = x"value" constructs and
replaces == by =, which is the correct operator to test the equality
of two strings with the test program.
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 <jacmet@sunsite.dk>
Following the introduction of the support of EABIhf as a second ARM
ABI, it is important to check whether the external toolchain provided
by the user actually uses the ABI that has been selected in the
Buildroot configuration. This commit introduces such a check by
looking at the 'Tag_ABI_VFP_args' tag of the architecture-specific
section of the ELF headers. This assumes that ELF is the binary format
used on ARM, which may not be the case on ARM noMMU systems (they use
the FLAT binary format), but Buildroot doesn't have support for such
systems at the moment.
Also ensure the correct CFLAGS are passed to the cross compiler for the
test, so the correct variant is used in case the toolchain is multilib.
[Peter: mention CFLAGS change]
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 <jacmet@sunsite.dk>
As noted by Yann E. Morin, the x$(...) = x"value" syntax is old and
ugly, and the easier to read "$(...)" = "value" can now be used
without problems.
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 <jacmet@sunsite.dk>
Until now, we were using the default ARM instruction set, as used by
the toolchain: the 32 bits ARM instruction set for the internal
backend, and for external toolchain, whatever default was chosen when
the toolchain was generated.
This commit adds support for the Thumb2 instruction set. To do so, it:
* provides a menuconfig choice between ARM and Thumb2. The choice is
only shown when Thumb2 is supported, i.e on ARMv7-A CPUs.
* passes the --with-mode={arm,thumb} option when building gcc in the
internal backend. This tells the compiler which type of
instructions it should generate.
* passes the m{arm,thumb} option in the external toolchain
wrapper. ARM and Thumb2 code can freely be mixed together, so the
fact that the C library has been built either ARM or Thumb2 and
that the rest of the code is built Thumb2 or ARM is not a problem.
[Peter: fix empty BR2_GCC_TARGET_MODE check]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The introduction of the EABIhf ABI requires a few updates to the
configuration options for external toolchains, in order to ensure that
the user doesn't do any invalid selection. In detail:
* The Linaro ARM toolchains now depend on BR2_ARM_EABIHF, because
that's the ABI they use, and it is incompatible with EABI. The
comment about the availability of Linaro toolchains is updated to
inform users selecting EABI that they should select EABIhf if they
want to see Linaro toolchains.
* The Sourcery CodeBench toolchains now depend on BR2_ARM_EABI,
because that's the ABI they use. A comment is added to inform users
that have selected EABIhf that Sourcery CodeBench are only
available when EABI is used.
* The Arago toolchains now depend on BR2_ARM_EABI, because that's the
ABI they use. The description of the ARMv7 Arago toolchain is also
slightly improved.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Now that we have a much better way of selecting between the various
VFP versions and capabilities, the BR2_VFP_FLOAT version no longer
makes sense. This commit gets rid of it, and adds the appropriate
Config.in.legacy code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As we are going to introduced a more advanced support of floating
point options for the ARM architecture, we need to adjust how the
soft-float option is handled. We replace the current hidden option
BR2_PREFER_SOFT_FLOAT option and the visible BR2_SOFT_FLOAT option by:
* A global hidden BR2_SOFT_FLOAT option, defined in arch/Config.in,
that tells whether the architecture-specific code is using software
emulated floating point. This hidden option can be used throughout
Buildroot to determine whether soft float is used or not.
* Per-architecture visible BR2_<arch>_SOFT_FLOAT options, for the
architecture for which it makes sense, which allows users to select
soft float emulation when needed.
This change will allow each architecture to have a different way of
presenting its floating point capabilities.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Buildroot already has the BR2_GCC_TARGET_{TUNE,ARCH,ABI,CPU} hidden
kconfig strings that allow per-architecture Config.in files to feed
the appropriate values of --with-{tune,arch,abi-cpu} when building
gcc, or the appropriate flags for the external toolchain wrapper.
This commit has two additional options:
BR2_GCC_TARGET_{FPU,FLOAT_ABI}, that allows to define the
--with-{fpu,float} gcc configure options for the internal backend, or
the -m{fpu,float-abi} options for the flags of the external toolchain
wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
... since we only support EABI now.
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>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
In 25c3160092 ("uClibc 0.9.31: remove stray kludges/conditions"), a
conditional that prevents the combination gcc 4.2-avr / C++ / locale
with uClibc 0.9.31 was removed. However, it turns out that the same
problem is affecting uClibc 0.9.33, described at
http://comments.gmane.org/gmane.comp.lib.uclibc.buildroot/24260.
Therefore, we prevent the combination of gcc 4.2-avr / C++ / locale to
happen.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
It was confusing to have two different toolchains with the
same label.
Signed-off-by: Jan Viktorin <xvikto03@stud.fit.vutbr.cz>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Using the newly introduced 'eglibc' package, this commit enables the
option of building a toolchain using the eglibc C library in the
Buildroot toolchain backend.
In details, this commit:
* Creates a choice to select uClibc or eglibc in the Buildroot
toolchain backend (in toolchain/toolchain-buildroot/Config.in), and
removes the fact that the Buildroot toolchain backend forcefully
enables uClibc (toolchain/Config.in).
* Creates a BUILDROOT_LIBC variables, which points to the package
implementing the C library (i.e either 'uclibc' or 'eglibc').
* Modifies the gcc-final and gcc-intermediate makefiles to use the
BUILDROOT_LIBC variable instead of hardcoding the use of uclibc.
* Ensures that TLS support is always enabled when building eglibc.
[Peter: fix commit text to refer to BUILDROOT_LIBC]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
In preparation for the introduction of the eglibc library to the
internal toolchain backend, the options that allow to enable/disable C
library features such as largefile, IPv6, RPC and so on now belong to
the uClibc package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Currently, when we need to do a conditional on the type of C library
used, we need to take into account the three toolchain backends. As we
are going to add eglibc support to the Buildroot toolchain backend, it
would become even uglier, so this patch introduces two new hidden
options: BR2_TOOLCHAIN_USES_UCLIBC and BR2_TOOLCHAIN_USES_GLIBC, that
exist regardless of the toolchain backend. The entire Buildroot code
base is converted to use those options.
Note that we have intentionally created only one option
(BR2_TOOLCHAIN_USES_GLIBC) for both glibc and eglibc, since they are
essentially the same, as far as Buildroot is concerned.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Instead of using the 'uclibc' target for all toolchain backends,
introduce more sensible target names for the external toolchain and
Crosstool-NG toolchain backend make targets.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
[Peter: update manual to match]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The libfloat package was removed in
accbd71154, and therefore since this
commit, the LIBFLOAT_TARGET variable is always empty. We get rid of
the stale references to this variable.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The GCC_STRIP_HOST_BINARIES variable was always defined to 'nope',
which means that the host binaries were never stripped. Get rid of the
corresponding code, which is not in use.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The KERNEL_SOURCE configuration option no longer exists in uClibc, so
there's no point in setting it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The default uClibc configurations strip the resulting binaries/libraries
and don't add debug symbols which is a problem when wanting to debug
issues.
Bind the buildroot BR2_STRIP_* option to uClibc .config DO_STRIP and
BR2_ENABLE_DEBUG to uClibc DO_DEBUG.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
For certain situations, users may want to install shared FLAT
libraries to the target filesystem even if FDPIC is used as the
primary binary format, or symmetrically users may want to install FDPIC
libraries to the target filesystem even if shared FLAT is used as the
primary binary format.
This commit allows that by:
* Offering additional Kconfig options to install shared FLAT or FDPIC
libraries even when those libraries are not selected as the primary
binary format.
* Preserving all Blackfin toolchain folders under the
TOOLCHAIN_EXTERNAL_DIR, instead of keeping only the one related to
the selected binary format.
* Adding some additional install targets that do the installation of
either the shared FLAT or FDPIC libraries when requested.
[Thomas: refactored code, adjusted commit log]
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
If ext-toolchain-wrapper was built with a gcc that uses hash-style 'gnu' by
default, the resulting binary might be unusable on other systems. The error
in this case is "Floating point exception".
Using hash-style 'both' solves this issue.
Signed-off-by: Patrick Ziegler <patrick.ziegler@fh-kl.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Instead of a long list of the ARMv7-A Cortex-A, use a conditional
based on BR2_GCC_TARGET_ARCH to hide/show toolchains that are only
usable on ARMv7-A.
However, in the comment related to Linaro toolchains, we keep
mentioning Cortex-A{5,8,9,15} because that's what users see when they
select their architecture variant.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We add support for Linaro 2013.04 and Linaro 2013.05 and remove
support for Linaro 2013.01 and Linaro 2013.02.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
