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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Remove old 2011.09 release. Allow MIPS64 cores on
2013.05 release since they are supported by the toolchain.
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
ADI officially supports the buildroot and related GNU toolchain for
Blackfin since ADI's 2012R1 release only. In order to avoid confusion,
it is better to remove the 2011R1 GNU toolchain for Blackfin. In
addition, the 2011R1 GNU toolchain for Blackfin doesn't support the
BF60x processors.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Acked-by: 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>
The external toolchain logic checks (and finds) the proper ARCH_LIB_DIR
and forcibly copies it to */lib even if it's in */lib64
This is all well until the check is done for create_lib64_symlinks which
only verifies if ARCH_SYSROOT_DIR/lib64 is a symlink, which in some
toolchain it's a real directory (like sourcery x86_64 2012.09) and thus
doesn't make the symlink in the target.
Fix this by also checking for a real directory.
Easily reproducible by running "make qemu_x86_64_defconfig", switching
to an external toolchain before build, building and then trying to run
the resulting image.
Closes bug #5054
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Adds the possibility to have a free-form CPU revision string and append it
to the target CPU. Only Blackfin actually uses this option.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Just introduce the symbol and options in arch generic Config.in.
Append FLAT format link flags to external toolchain wrapper.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When a FOO_SITE variable ends in a slash and gets joined with a
FOO_SOURCE variable like $(FOO_SITE)/$(FOO_SOURCE), the resulting URI
has a double slash. While double-slashes are fine in unix paths, they
are reserved in URIs - the part following '//' must be an authority.
Signed-off-by: Shawn J. Goff <shawn7400@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Commit 79828fc01d (toolchain-external:
update ARM Linaro toolchains) accidently broke the URL for the Linaro
2013.01 toolchain by replacing a .bz2 extension by .bz. This patch
fixes this problem.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The x86/x86-64 CodeSourcery toolchains use some weird locations for
the gdbserver binary:
$ find . -name 'gdbserver'
./i686-pc-linux-gnu/libc/atom/usr/bin/gdbserver
./i686-pc-linux-gnu/libc/atom/usr/lib/bin/gdbserver
./i686-pc-linux-gnu/libc/core2/usr/bin/gdbserver
./i686-pc-linux-gnu/libc/core2/usr/lib64/bin/gdbserver
./i686-pc-linux-gnu/libc/usr/lib/bin/gdbserver
./i686-pc-linux-gnu/libc/usr/lib64/bin/gdbserver
Notice that it's sometimes hidden in a usr/{lib,lib64}/bin
directory. This patch changes the gdbserver logic to also try in this
location.
Originally based on work done by Daniel Nilsson, visible at
http://patchwork.ozlabs.org/patch/155767/.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
git.xilinx.com is no longer available (moved to github), and github
doesn't allow downloading the tarball blobs directly, so use a local
mirror on sources.buildroot.net instead.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add the AArch64 Linaro toolchains 2013.02 and 2013.03, remove 2012.11
and 2012.12.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add the ARM Linaro toolchains 2013.02 and 2013.03, remove 2012.11 and
2012.12.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The existing Microblaze toolchains that we have have the annoying
property of being based on a very old glibc version: 2.3.6. Xilinx
provides newer toolchains with glibc 2.14, generated by Crosstool-NG,
but they are only available as part of a huge Git repository that
contains the gcc, Linux, binutils, glibc sources unpacked (4.4 GB
total), which makes is very unpractical.
I contacted the Xilinx person who did those toolchains, but they
apparently didn't intend to change that anytime soon.
So, we have created a tarball for those toolchains, adding a
README.txt file in the tarball that points back to the original
location that contains the source code for them. Those tarballs are
hosted on sources.buildroot.net.
This commit then adds support for those two new external toolchains,
one for little endian Microblaze, another one for big endian
Microblaze.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The external toolchain wrapper sets sysroot etc. to an absolute path.
By changing this to a relative path, it is possible to move the host
directory to a different location and still have a working build
system.
This only works for a downloaded external toolchain. For a pre-installed
external toolchain, it is possible to move the host directory to a
different location, but not the external toolchain directory (it does work
if the external toolchain directory lies within the host directory). For
an internal or crosstool-ng toolchain, there is no wrapper so updating the
sysroot path should be done in a different way.
See http://lists.busybox.net/pipermail/buildroot/2012-February/050371.html
for information about others things to do to make the host directory
relocatable.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Remove the old 2010RC1 toolchain and add the new 2012R2-RC2 toolchain.
On related good news the new toolchain fixes:
http://autobuild.buildroot.net/results/eac5bd4f4766d98431e72a3c81492a962c85fa98/
since it's got unshare() support now.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Thus, the failing step can be easily extracted by autobuilders,
to ease with post-mortem analysis.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
