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>
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>
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>
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 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>
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>
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>
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>
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>
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>
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>
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>
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>
