Commit Graph

2203 Commits

Author SHA1 Message Date
Peter Korsgaard
577021e81b Merge branch 'next'
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-06-01 17:55:16 +02:00
Yann E. MORIN
49648d4b01 toolchain/helper: don't follow symlinks when copying libs to target
In 2a87b64 (toolchain-external: align library locations in target and
staging dir), copying the libraries from the sysroot to the target was
changed to a simple find-based solution.

To be sure that the staging directory was entered to find the libraries,
in case the variable was pointing to a symlink, the -L clause to find
was used.

However, that causes extraneous libraries to be copied over.

For example, a ct-ng toolchain would have this sysroot (e.g for an arm
32-bit toolchain):

    .../sysroot/lib/
    .../sysroot/lib32 -> lib
    .../sysroot/lib64 -> lib
    .../sysroot/usr/lib/
    .../sysroot/usr/lib32 -> lib
    .../sysroot/usr/lib64 -> lib

Which we would carry as-is to our own sysroot.

But then, in target, our skeleton creates the /lib/ and /usr/lib
directories, with the necessary lib32 or lib64 symlink pointing to it.
In this case, a lib32->lib symlink is created, but no lib64 symlink
since this is a 32-bit architecture.

To copy the required libraries from staging into target, we scan the
staging directory for all occurences of the required libraries, and copy
them over to target, keeping the same directory layout relative to the
sysroot.

For example:
    .../sysroot/usr/lib/libfoo.so   -->  .../target/usr/lib/libfoo.so
    .../sysroot/usr/lib32/libbar.so -->  .../target/usr/lib32/libbar.so
    .../sysroot/usr/lib64/libbuz.so -->  .../target/usr/lib64/libbuz.so

So, when we copy over the libraries from our staging to the target
directory, the "find -L .../sysroot -name libblabla.so.*" would find
multiple instances of libblabla, each in the /usr/lib /usr/lib32 and
/usr/lib64 locations (they are all the exact same file, though).

Since we do have the /usr/lib32->lib symlink, all is OK (but there are
two copies going on, which could be avoided). However, since we do not
have the /usr/lib64->lib symlink, the /usr/lib64/ directory is created.

This was very difficult to observe, as no /lib64/ directory is created,
only the /usr/lib64/ one was. To top it off, this only happens with a
merged /usr, which does not seem like not a common case without systemd.

Since the reason to use -L was to be sure to enter our staging
directory, we just need to ensure that the path ends up with a slash, as
was already talked about in this thread:
    http://lists.busybox.net/pipermail/buildroot/2016-April/159737.html

After further discussion, it turns out that the original patch came along
because of the confusion between output/staging (which is a symlink) and
$(STAGING_DIR) which expands to output/host/usr/<tupple>/sysroot (which is
never a symlink), so the symlink handling isn't really needed at all.

[Peter: drop description comment, extend description]
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>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-05-30 22:53:54 +02:00
Clayton Shotwell
9891e5cbfa toolchain-external: correct hash value for Linaro AArch64 toolchain source
The aarch64 Linaro toolchain source hash is not correct, probably due
to a copy/paste error. The new hash has been verified by downloading
the tarball, validating the signature, and computing the hash.

Signed-off-by: Clayton Shotwell <clayton.shotwell@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-24 17:32:47 +02:00
Vicente Olivert Riera
794935068b toolchain: improve SSP logic
Don't enable SSP support on external toolchains just because they use
glibc or musl. Instead of that, make the external toolchains explictily
declare if they support SSP or not. And also add a check to detect SSP
support when using custom external toolchains.

For internal toolchains we always enable SSP support for glibc and musl.

Fixes:

  http://autobuild.buildroot.net/results/ac7c9b3ad2e52abfe6b79a80045e4218eeb87175/

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
[Thomas:
 - remove uClibc-specific SSP check, since there is now a generic
   check being done.
 - send potential compilation errors caused by the SSP check to
   oblivion, in order to avoid causing confusion for the user.
 - add autobuilder reference.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-23 21:07:24 +02:00
Romain Naour
04c9d65039 toolchain-external: bump CodeSourcery NIOSII to 2016.05
The toolchain still use binutils 2.25 without the fix for PR19405.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-23 17:36:11 +02:00
Thomas Petazzoni
a8e6f52f0c toolchain: musl support is no longer experimental
Our musl support has now been around for quite some time, numerous
packages have been fixed (although admittedly not all). It's time to no
longer call our musl support "experimental": things are now expected to
be working with musl just like with the other two C libraries we
support.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-05-17 08:53:12 +02:00
Thomas Petazzoni
500de2598a toolchain: remove eglibc support
The eglibc support has been marked deprecated since 2015.08, so it's
time to remove it.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-05-17 08:48:23 +02:00
Gustavo Zacarias
51800d20b9 toolchain: add 4.6.x choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-05-16 21:15:18 +02:00
Romain Naour
8389b62352 toolchain-external: fix user provided libraries deployment
In commit 919b4f9eab the internal symbol
LIB_EXTERNAL_LIBS was renamed TOOLCHAIN_EXTERNAL_LIBS but the find and
replace command also renamed BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS to
BR2_TOOLCHAIN_EXTRA_TOOLCHAIN_EXTERNAL_LIBS which doesn't exist.

So user provided libraries defined in BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS
are not copied anymore to staging and target directories.

For example:
BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS="libasan.* libubsan.*"

Simply revert this change by renaming
BR2_TOOLCHAIN_EXTRA_TOOLCHAIN_EXTERNAL_LIBS to BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-13 15:05:25 +02:00
Thomas Petazzoni
60b843edf0 toolchain-external: fix registration of hook for Sourcery Aarch64 toolchain
As noticed by Romain Naour, commit
4d39ca1c2a ("toolchain-external: fix
installation for CodeSourcery AArch64 toolchain") has a small bug where
a post-install hook doing fixups in TARGET_DIR was registered as a
staging installation hook while it should have been registered as a
target installation hook. This commit fixes this inconsistency.

Reported-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-08 15:05:14 +02:00
Gustavo Zacarias
8490e8333d toolchain-external: remove Sourcery PowerPC toolchains
These are running long on the teeth - the bundled (e)glibc versions
are very old with several security bugs, they don't work reliably with
-Os and have several build failures related to internal compiler
errors such as:

http://autobuild.buildroot.net/results/fe7/fe7bdba5faf199275aedea2918705b5d19d228bf/
http://autobuild.buildroot.net/results/935/935ac42c30ed893939c06c077534f060aed80e9a/
http://autobuild.buildroot.net/results/a47/a476af82c8fe4a279117314b278b08af9a08fe54/
http://autobuild.buildroot.net/results/cae/cae720b5096be2672b4dc1311ae3fc4ed06a3b53/

The situation will not provide, and will in fact get worse with older kernel
headers precluding modern package versions and the old gcc version doing as
well so remove them.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Thomas:
 - remove no longer needed comment in liquid-dsp Config.in file, as
   noticed by Romain Naour.
 - add Config.in.legacy options, as noticed by Romain Naour.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-01 15:05:34 +02:00
Romain Naour
230cfce93d toolchain-external: bump CodeSourcery MIPS to 2016.06-8
Add hash for the toolchain sources.

Runtime tested with Qemu with qemu_mips_malta_defconfig

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-01 14:56:06 +02:00
Romain Naour
14a75e09b9 toolchain-external: bump CodeSourcery AMD64 to 2015.11-139
>From getting-started.pdf:
- Linker bug fix.
- Fix CVE 2015-7547 getaddrinfo.
- Breakpoint in non-existent file bug fix.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-01 14:46:17 +02:00
Romain Naour
8ed38d8b4b toolchain-external: bump CodeSourcery NiosII to 2015.11-130
>From getting-started.pdf:
- DWARF signed LEB128 encoding fix
- Fix CVE 2015-7547 getaddrinfo
- Breakpoint in non-existent file bug fix

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-01 14:46:06 +02:00
Jörg Krause
8f972c2aed toolchain-external: add GCC 6.x option
Commit 519d83bfa0 adds support for GCC
6. Add an GCC 6.x option for external toolchains, too.

Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-01 14:41:47 +02:00
Thomas Petazzoni
31d1df0c7c toolchain-external: bump version of Linaro AArch64 toolchain
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-30 21:10:36 +02:00
Thomas Petazzoni
df4f64c77c toolchain-external: bump version of Linaro ARMeb toolchain
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-30 21:10:35 +02:00
Thomas Petazzoni
292fa50452 toolchain-external: bump version of Linaro ARM toolchain
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-30 21:10:34 +02:00
Romain Naour
e7a682be31 toolchain-external: bump CodeSourcery aarch64 to 2014.11
Runtime tested using qemu_aarch64_virt_defconfig.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
[Thomas: updated to the latest master branch.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-30 18:19:46 +02:00
Romain Naour
4d39ca1c2a toolchain-external: fix installation for CodeSourcery AArch64 toolchain
The extracted toolchain sources contains a single symlink in the
aarch64-linux-gnu/libc/lib directory wich is lost during Buildroot's
staging install.

aarch64-linux-gnu/libc/lib/ld-linux-aarch64.so.1 -> ../lib64/ld-2.18.so

Add a custom post install staging and target hooks to create it
manually.

Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: also make the same tweak in the target.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-30 15:41:40 +02:00
Thomas Petazzoni
519d83bfa0 gcc: add support for gcc 6
This commit adds the support for gcc 6. This release allows to remove
a large number of our gcc patches, mainly thanks to the Xtensa and
musl related patches being merged upstream.

Patches kept with no changes:

 100-uclibc-conf.patch
 301-missing-execinfo_h.patch
 810-arm-softfloat-libgcc.patch
 830-arm_unbreak_armv4t.patch
 840-microblaze-enable-dwarf-eh-support.patch
 860-cilk-wchar.patch
 890-fix-m68k-compile.patch

Patches dropped because they have been merged upstream, or were
already upstream backports:

 120-gcc-config.gcc-fix-typo-for-powerpc-e6500-cpu_is_64b.patch (merged)
 850-libstdcxx-uclibc-c99.patch (merged in a different form, see
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393)
 870-xtensa-add-mauto-litpools-option.patch (upstream backport)
 871-xtensa-reimplement-register-spilling.patch (upstream backport)
 872-xtensa-use-unwind-dw2-fde-dip-instead-of-unwind-dw2-.patch (upstream backport)
 873-xtensa-fix-_Unwind_GetCFA.patch (upstream backport)
 874-xtensa-add-uclinux-support.patch (upstream backport)
 900-libitm-fixes-for-musl-support.patch (upstream backport)
 901-fixincludes-update-for-musl-support.patch (upstream backport)
 902-unwind-fix-for-musl.patch (upstream backport)
 903-libstdc++-libgfortran-gthr-workaround-for-musl.patch (upstream backport)
 904-musl-libc-config.patch (upstream backport)
 905-add-musl-support-to-gcc.patch (upstream backport)
 905-add-musl-support-to-gcc.patch (upstream backport)
 906-mips-musl-support.patch (upstream backport)
 907-x86-musl-support.patch (upstream backport)
 908-arm-musl-support.patch (upstream backport)
 909-aarch64-musl-support.patch (upstream backport)

Successfully build-time and run-time tested with
qemu_arm_vexpress_defconfig, using gcc 6.x, both in uClibc and musl
configurations.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-04-27 23:11:53 +02:00
Romain Naour
4b201090d8 toolchain/helper: update check_unusable_toolchain comment
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-27 22:19:19 +02:00
Romain Naour
6bb0355300 toolchain-external: move the sysroot check to helper function
The sysroot toolchain support check is duplicated at two locations in
the external toolchain infra. So move it inside the
check_unusable_toolchain helper that is called when the toolchain
package is configured (TOOLCHAIN_EXTERNAL_CONFIGURE_CMDS).

The check in TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS can be safely
removed since it's already done in check_unusable_toolchain helper.

The check in TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS was removed by
2a87b64f8e.

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-27 22:18:35 +02:00
Romain Naour
c32c390e13 toolchain-external: add a check for unsupported toolchains
Some toolchain can't be used by Buildroot due to sysroot location
issue, so the $(ARCH)-linux-gnu-gcc -print-file-name=libc.a command
return only "libc.a"

This lead to an error during the header check version helper,
so these toolchains can't be imported into Buildroot.

cc1: fatal error: $PWD/libc.a/usr/include/linux/version.h: No such file or directory
compilation terminated.
support/scripts/check-kernel-headers.sh: line 38: /tmp/check-headers.4V5PPF: Permission denied

This issue happen with the first linaro 2015.11 [1] release and
CodeSourcery standard edition [2].

Here is the sysroot directory tree for linaro 2015.11:
$ ls libc/arm-linux-gnueabihf
etc  lib  sbin  usr  var

Here is the sysroot directory tree for CodeSourcery standard:
$ ls libc/sgxx-glibc
etc  lib  lib64  sbin  usr  var

Add a check to error out with an explicit error message

The check don't use toolchain_find_libc_a function directly since
"realpath -f" is used internally and return an absolute path.

[1] https://bugs.linaro.org/show_bug.cgi?id=1995#c7
[2] http://lists.busybox.net/pipermail/buildroot/2014-October/110696.html

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-27 22:18:05 +02:00
Thomas Petazzoni
ed2a15b791 toolchain-external: remove useless shell continuations
When a message with MESSAGE, we can print it as the first command of
the command sequence, and in this case, we don't need to use a shell
continuation.

In one case, the call to MESSAGE is moved a few lines up in the
sequence of commands.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-25 22:55:29 +02:00
Thomas Petazzoni
12584c2c70 toolchain-external: rename Blackfin related special variables
As suggested by Arnout, this commit renames:

 - TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FDPIC to
   TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FDPIC

 - TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FLAT to
   TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FLAT

Which makes it clear that those variables are installing libraries to
the target, and make their naming more consistent with the naming of
other variables in the file.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-25 22:48:58 +02:00
Thomas De Schampheleire
919b4f9eab toolchain-external: unify LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS
With the alignment of toolchain library location in target and staging,
there is no need anymore for the distinction between LIB_EXTERNAL_LIBS and
USR_LIB_EXTERNAL_LIBS. Unify them into TOOLCHAIN_EXTERNAL_LIBS.

Related, update the help text of
BR2_TOOLCHAIN_EXTRA_TOOLCHAIN_EXTERNAL_LIBS.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-25 22:48:56 +02:00
Thomas De Schampheleire
2a87b64f8e toolchain-external: align library locations in target and staging dir
The toolchain-external logic is roughly:
- populate the staging dir by rsyncing the entire ${ARCH_LIB_DIR} and
  usr/${ARCH_LIB_DIR} from sysroot.
- populate the target dir by explictly copying some libraries from sysroot
  into target/lib and some other libraries in target/usr/lib, the split
  being hardcoded into buildroot regardless of the location in the sysroot.

This means that a library libfoo could be located in:
  staging/lib/libfoo.so
  target/usr/lib/libfoo.so

When debugging an application that links against this library, gdb will
fruitlessly search for 'usr/lib/libfoo.so' in staging, and then suggest to
use 'set solib-search-path' which is a hack, really.

To solve the problem, we need to make sure that libraries from the toolchain
are installed in the same relative location in staging and target.
Achieve this by:
- replacing the convoluted search for libraries using for+find in sysroot
  with a simple find in staging.
- determining DESTDIR for each library individually based on the location in
  staging.
- treating LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS equivalently

These changes also allow for the removal of most arguments to
copy_toolchain_lib_root in the method itself and their callers.

Test procedure:
- set configuration for a given toolchain
- make clean toolchain
- find output/target | sort > /tmp/out-before
- apply patch
- make clean toolchain
- find output/target | sort > /tmp/out-after
- diff -u /tmp/out-before /tmp/out-after

The only changes should be some libraries moving from lib to usr/lib or vice
versa. Notable examples being libstdc++ and libatomic.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas:
 - use -L instead of -follow in the find invocation, as suggested by
   Arnout.
 - move the BR2_STATIC_LIBS condition as a make condition rather than
   a shell condition, as suggested by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-25 22:46:28 +02:00
Thomas De Schampheleire
10e905f83d toolchain-external: extract installation of gdbserver to separate define
The installation of the gdbserver binary has no relation to the installation
of the target libraries. Moving it to a separate define improves the
understandability of the code and makes later refactoring easier.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[Thomas:
 - move the BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY condition as a make
   condition rather than a shell condition, as suggested by Romain
   Naour.
 - rename the TOOLCHAIN_EXTERNAL_INSTALL_GDBSERVER variable to
   TOOLCHAIN_EXTERNAL_INSTALL_TARGET_GDBSERVER as suggested by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-25 22:05:45 +02:00
Thomas De Schampheleire
38040b2e1f toolchain-external: blackfin: install FDPIC libraries also to staging
For external Blackfin toolchains with BR2_BFIN_INSTALL_FDPIC_SHARED set,
the FDPIC shared libraries are currently only copied to the target
directory, not to staging.

For debugging purposes, an unstripped copy in staging is necessary.
Moreover, this change will simplify a subsequent change that lines up the
location of shared libraries between target and staging directories.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-25 21:56:34 +02:00
Thomas De Schampheleire
4896b7c96f toolchain-external: remove unused calculation of ARCH_SUBDIR
In TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS, ARCH_SUBDIR is calculated but not
used, and can thus be removed. Since SYSROOT_DIR is only used for the
calculation of ARCH_SUBDIR, it can be removed too.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-21 23:30:20 +02:00
Romain Naour
5dce3c05b5 toolchain-external: CodeSourcery NiosII 2015.11 affected by PR19405
See bug report https://sourceware.org/bugzilla/show_bug.cgi?id=19405

Fixes:
http://autobuild.buildroot.net/results/ee562524c5b12191e584ceae89006c5a5103e700

Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas:
 - rename BR2_TOOLCHAIN_BINUTILS_HAS_BUG_19405 to
   BR2_TOOLCHAIN_HAS_BINUTILS_BUG_19405
 - propagate to the qwt package, which is now selecting
   BR2_PACKAGE_QT_GUI_MODULE.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-20 23:20:58 +02:00
Thomas Petazzoni
6cb4814c87 arch/x86: remove support for i386
The Linux kernel doesn't even support i386 anymore, there is no NPTL
support for i386 and uClibc-ng only supports NPTL on x86, so there is
essentially no usable thread implementation. Most likely glibc and
musl also don't support i386 either. So it's time to remove the
support for this architecture variant.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-18 23:38:34 +02:00
Thomas Petazzoni
ee47352920 toolchain-buildroot: don't show musl on noMMU platforms
While musl has recently gained noMMU support for the sh2 platform, we
don't support this yet. So for the time being, let's not show musl as
an available C library on noMMU platforms. This is for example
important on ARM noMMU: ARM is supported by musl, but not its noMMU
variants.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-04-08 12:09:52 +02:00
Thomas Petazzoni
c6724b4f47 toolchain-buildroot: update glibc comment for noMMU
glibc is not available for noMMU platforms, so it doesn't make sense
to show the comment about glibc requiring dynamic libraries on noMMU
platforms.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-04-08 12:09:28 +02:00
Thomas Petazzoni
4f90f55dc4 toolchain-external: fix getent installation with Codescape MIPS toolchains
When a toolchain is glibc based, the getent package assumes that
$(STAGING_DIR)/usr/bin contains the getent program. Unfortunately, the
Codescape MIPS toolchains do not conform with this:
$(STAGING_DIR)/usr/{bin,sbin} are empty, and instead three directories
are provided: bin-o32, bin-n32 and bin-n64 (ditto for sbin), one for
each supported MIPS ABI.

Since this is a toolchain-specific oddity, we handle it by adding a
post-install fixup hook that creates $(STAGING_DIR)/usr/{bin,sbin} as
symbolic link to the appropriate directory.

Fixes:

   http://autobuild.buildroot.org/results/9c0ee836021553319f166f9de88750535aee0a58/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-30 18:10:16 +02:00
Thomas Petazzoni
42735cb9b9 toolchain: introduce BR2_TOOLCHAIN_HAS_LIBATOMIC
Until now, we were assuming that whenever you have gcc 4.8, libatomic
is available. It turns out that this is not correct, since libatomic
will not be available if thread support is disabled in the toolchain.

Therefore, __atomic_*() intrinsics may not be available even if the
toolchain uses gcc 4.8.

To solve this problem, we introduce a BR2_TOOLCHAIN_HAS_LIBATOMIC
boolean, which indicates whether the toolchain has libatomic. It is
the case when you are using gcc >= 4.8 *and* thread support is
enabled. We then use this new BR2_TOOLCHAIN_HAS_LIBATOMIC to define
BR2_TOOLCHAIN_HAS_ATOMIC.

As explained in the comment, on certain architectures, libatomic is
technically not needed to provide the __atomic_*() intrinsics since
they might be all built-in. However, since libatomic is only absent in
non-thread capable toolchains, it is not worth making things more
complex for such seldomly used configuration.

Note that we are introducing the intermediate
BR2_TOOLCHAIN_HAS_LIBATOMIC option because it will be useful on its
own for certain packages.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: improve Config.in comment using a suggestion from Yann.]
2016-03-20 23:40:03 +01:00
Yann E. MORIN
5b96eb6703 toolchain/external: add hashes for actual sources
As we currently download the actual sources as part of saving the
legal-info, we do not check the hashes of those downloads.

That's because, during legal-info, there is not package involved, and
thus there's no path to an actual .hash file.

However, this precludes legal-info from working in off-line mode. A
subsequent patch will make it possible to do so, and actual sources will
be downloaded as another classical package download.

This will have two consequences:

  - first, we will be able to add hashes for actual sources, so we can
    ensure their integrity,

  - second, and as a direct consequence of the above, when a .hash file
    is present, it would have to list all the hashes for that package,
    or that would be treated as an error.

Currently, the only package that falls in this case is the external-
toolchain, for which we have means to retrieve the sources for some of
the toolchains.

So we just add hashes for those actual external-toolchain sources we may
have to download.

Those hashes are not used for now, but they'll come into play a few
patches down.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-19 15:10:18 +01:00
Gustavo Zacarias
3ece3faafa toolchain: add 4.5.x choice for headers
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-14 13:11:59 +01:00
Jason Abele
ddd87a7e0b toolchain: switch linaro to https urls
Signed-off-by: Jason Abele <jason@nextthing.co>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-09 22:59:31 +01:00
Yann E. MORIN
6c294b83db toolchain: also source the musl package
We do source the glibc and uClibc packages in the toolchain menu,
because they do provide user-visible options. However, we do not so
far source the musl Config.in file

However, in 822be87 (toolchain: include C libraries in legal-info),
a Config.in file for musl was explicitly created, so that:
  - legal-info would work (needed at the time, probably no longer needed
    nowadays),
  - the appropriate packages are enabled, like netbsd-queue or kernel
    headers.

Yet, we do not source musl/Config.in, which means we do not get
netbsd-queue or kernel-headers to be selected:

    $ make distclean; make menuconfig
        Toolchain  --->
          C library ---> musl
      save-and-exit
    $ grep BR2_PACKAGE_LINUX_HEADERS .config
        [nothing]
    $ grep BR2_PACKAGE_NETBSD_QUEUE .config
        [nothing]

Fix that by sourcing musl/Config.in at the same place we source glibc
and uClibc.

Normally, we do have a check in place that verifies that a package
that is not enabled is not a dependency of another package that is
enabled. However, musl is only a dependency of host-gcc-final, which
is a host package and has no corresponding BR2_PACKAGE_HOST_GCC_FINAL.
Thus host-gcc-final is not in the PACKAGES variable, and thus does not
trigger our check.

Reported-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-08 21:59:40 +01:00
Vicente Olivert Riera
2b3fa6b4b7 toolchain: bump Codescape toolchains to version 2015.10
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-08 21:02:16 +01:00
Thomas Petazzoni
df4d908ed5 toolchain-external: bump musl toolchain to 1.1.12
While the prebuilt musl toolchains provided by http://musl.codu.org/
had not been updated in a while, a new release based on musl 1.1.12
has been put online in December 2015. This commit updates our external
toolchain package to use this new pre-built toolchain.

Compared to the previous 1.1.6 toolchain, there are some changes:

 - The MIPS big endian soft-float variant is no longer available.
 - The Microblaze variant is no longer available.
 - SuperH 4, both little and big endian, variants have been added.
 - The components have been updated: gcc 5.3 is used, binutils 2.25.1,
   and of course musl 1.1.12.

Besides the update itself, in this commit, we are:

 - Making the musl toolchain non-selectable on MIPS big endian
   soft-float.

 - Making the musl toolchain actually work on MIPS little endian
   soft-float, by downloading the right tarball and setting up the
   right symbolic link.

 - Removing support for the Microblaze variant, and adding support for
   the SH4 variants.

All variants except armeb have been boot tested under Qemu, up to a
Busybox shell prompt. armeb has not been tested due to the lack of a
Qemu configuration for this architecture.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-05 15:54:35 +01:00
Peter Korsgaard
28cd1ed30a Merge branch 'next'
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-03-02 21:25:00 +01:00
Gustavo Zacarias
2b9a7128e7 glibc: remove version 2.21
Mask out glibc for sparc as well since it's no longer available.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-29 22:57:26 +01:00
Peter Korsgaard
c0c3d7d6c9 toolchain-external/Config.in: Fix Linaro typo
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-21 22:19:54 +01:00
Thomas Petazzoni
6856e417da toolchain: add BR2_TOOLCHAIN_HAS_{SYNC_x, ATOMIC} hidden booleans
Currently, Buildroot provides one BR2_ARCH_HAS_ATOMICS boolean option
to indicate whether the architecture supports atomic operations or
not. However, the reality of atomic operations support is much more
complicated and requires more than one option to be expressed
properly.

There are in fact two types of atomic built-ins provided by gcc:

 (1) The __sync_*() family of functions, which have been in gcc for a
     long time (probably gcc 4.1). They are available in variants
     operating on 1-byte, 2-byte, 4-byte and 8-byte integers. Some
     architectures implement a number of variants, some do not
     implement any, some implement all of them.

     They are now considered "legacy" by the gcc developers but are
     nonetheless still being used by a significant number of userspace
     libraries and applications.

     https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html

 (2) The __atomic_*() family of functions, which have been introduced
     in gcc 4.7. They have been introduced in order to support C++11
     atomic operations. In gcc 4.8, they are available on all
     architectures, either built-in or in the libatomic library part
     of the gcc runtime (in which case the application needs to be
     linked with -latomic). In gcc 4.7, the __atomic_*() intrinsics
     are only supported on certain architectures, since libatomic did
     not exist at the time.

For (1), a single BR2_ARCH_HAS_ATOMICS is not sufficient, because
depending on the architecture, some variants may or may not be
available. Setting BR2_ARCH_HAS_ATOMICS to false as soon as one of the
variant is missing would cause a large number of packages to become
unavailable, even if they in fact use only more common variants
available on a large number of architectures. For this reason, we've
chosen to introduce four new Config.in options:

 - BR2_TOOLCHAIN_HAS_SYNC_1
 - BR2_TOOLCHAIN_HAS_SYNC_2
 - BR2_TOOLCHAIN_HAS_SYNC_3
 - BR2_TOOLCHAIN_HAS_SYNC_4

Which indicate whether the toolchain support 1-byte, 2-byte, 4-byte
and 8-byte __sync_*() built-ins respectively.

For (2), we introduce a BR2_TOOLCHAIN_HAS_ATOMIC, which indicates if
the __atomic_*() built-ins are available. Note that it is up to the
package to link with -latomic when gcc is >= 4.8. Since __atomic_*()
intrinsics for all sizes are supported starting

We conducted a fairly large analysis about various architectures
supported by Buildroot, as well as with a number of different
toolchains, to check which combinations support which variant. To do,
we linked the following program with various toolchains:

int main(void)
{
	uint8_t a;
	uint16_t b;
	uint32_t c;
	uint64_t d;

	__sync_fetch_and_add(&a, 3);
	__sync_fetch_and_add(&b, 3);
	__sync_fetch_and_add(&c, 3);
	__sync_fetch_and_add(&d, 3);

	__sync_val_compare_and_swap(&a, 1, 2);
	__sync_val_compare_and_swap(&b, 1, 2);
	__sync_val_compare_and_swap(&c, 1, 2);
	__sync_val_compare_and_swap(&d, 1, 2);

	__atomic_add_fetch(&a, 3, __ATOMIC_RELAXED);
	__atomic_add_fetch(&b, 3, __ATOMIC_RELAXED);
	__atomic_add_fetch(&c, 3, __ATOMIC_RELAXED);
	__atomic_add_fetch(&d, 3, __ATOMIC_RELAXED);

	__atomic_compare_exchange_n(&a, &a, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);
	__atomic_compare_exchange_n(&b, &b, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);
	__atomic_compare_exchange_n(&c, &c, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);
	__atomic_compare_exchange_n(&d, &d, 2, 1,  __ATOMIC_RELAXED,  __ATOMIC_RELAXED);

	return 0;
}

And looked at which symbols were unresolved. For the __atomic_*()
ones, we tested with and without -latomic to see which variants are
built-in, which variants require libatomic. This testing effort has
led to the following results:

                __sync       __atomic    gcc
               1  2  4  8    1  2  4  8
ARC            Y  Y  Y  -    Y  Y  Y  L   4.8 [with BR2_ARC_ATOMIC_EXT]
ARC            -  -  -  -    L  L  L  L   4.8 [without BR2_ARC_ATOMIC_EXT]
ARM            Y  Y  Y  X    Y  Y  Y  Y   4.8, 4.7
ARM            Y  Y  Y  -                 4.5
AArch64        Y  Y  Y  Y    Y  Y  Y  Y   4.9, 5.1
Bfin           -  -  Y  -                 4.3
i386 (i386)    -  -  -  -    L  L  L  L   4.9
i386 (i486..)  Y  Y  Y  -    L  L  L  L   4.9 [i486, c3, winchip2, winchip-c6]
i386 (> i586)  Y  Y  Y  Y    L  L  L  L   4.9
Microblaze     -  -  Y  -    L  L  Y  L   4.9
MIPS           Y  Y  Y  -    Y  Y  Y  L   4.9
MIPS64         Y  Y  Y  Y    Y  Y  Y  Y   4.9
NIOS 2         Y  Y  Y  -    Y  Y  Y  L   4.9, 5.2
PowerPC        Y  Y  Y  -    Y  Y  Y  L   4.9
SuperH         Y  Y  Y  -    Y  Y  Y  L   4.9
SPARC          -  -  -  -    L  L  L  L   4.9
SPARC64        Y  Y  Y  Y    Y  Y  Y  Y   4.9
x86_64         Y  Y  Y  Y    Y  Y  Y  Y   4.7, 4.9
Xtensa         Y  Y  Y  -    Y  Y  Y  Y   4.9

Notes:

 * __atomic built-ins appeared in gcc 4.7, so for toolchais older than
   that, the __atomic column is empty.

 * Y means 'supported built-in'

 * L means 'supported via linking to libatomic' (only for __atomic
   functions)

 * X indicates a very special case for 8 bytes __sync built-ins on
   ARM. On ARMv7, there is no problem, starting from gcc 4.7, the
   __sync built-in for 8 bytes integers is implemented, fully in
   userspace. For cores < ARMv7, doing a 8 bytes atomic operation
   requires help from the kernel. Unfortunately, the libgcc code
   implementing this uses the __write() function to display an error,
   and this function is internal to glibc. Therefore, if you're using
   glibc everything is fine, but if you're using uClibc or musl, you
   cannot link an application that uses 8 bytes __sync
   operations. This has been fixed as part of gcc PR68095, merged in
   the gcc 5 branch but not yet part of any gcc release.

 * - means not supported

This commit only introduces the new options. Follow-up commits will
progressively change the packages using BR2_ARCH_HAS_ATOMICS to use
the appropriate BR2_TOOLCHAIN_HAS_SYNC_x or BR2_TOOLCHAIN_HAS_ATOMIC
until the point where BR2_ARCH_HAS_ATOMICS can be removed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-06 11:16:00 +01:00
Yann E. MORIN
e6d1a2073b toolchain/external: newer Linaro toolchains do not provide source code
Currently, we have a pattern-matching that automatically derives the
the source tarball filename from the binary tarball filename.

However, the latest Linaro toolchains no longer follow that scheme (and
do not even readily provide the sources...).

Remove the generic pattern-matching, and explicitly set the source
tarball name for those toolchains that do have a source tarball readily
available.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-03 23:46:27 +01:00
Thomas De Schampheleire
335f331ff2 toolchain: copy_toolchain_lib_root: rename LIBSPATH to LIBPATHS
LIBSPATH is populated based on a find with a pattern that can look like:
    libfoo*.so
and thus the output of the find will contain all file paths that match this
pattern.

Unfortunately, the name LIBSPATH suggests that only one entry is returned,
rather than possibly multiple.

As this code is quite complex, use the more accurate name LIBPATHS iso
LIBSPATH.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-03 23:46:00 +01:00
Romain Naour
2956afbdbc toolchain-external: bump Linaro ARMEB to 2015.11-2
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas: only add the symlink with the old 2014.09 Linaro toolchain,
for the newer ones, it is no longer needed.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-01 19:38:02 +01:00