buildroot/toolchain, branch 2016.05

toolchain/helper: don't follow symlinks when copying libs to target

2016-05-30T20:53:54+00:00

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//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" Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Cc: Thomas De Schampheleire Cc: Peter Korsgaard Signed-off-by: Peter Korsgaard

toolchain-external: correct hash value for Linaro AArch64 toolchain source

2016-05-24T15:32:47+00:00

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 Signed-off-by: Thomas Petazzoni

toolchain: improve SSP logic

2016-05-23T19:07:24+00:00

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

toolchain-external: fix user provided libraries deployment

2016-05-13T13:05:25+00:00

In commit 919b4f9eab3e6dcd18cf9220af2c9bb2ca3e5098 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 Signed-off-by: Thomas Petazzoni

toolchain-external: fix registration of hook for Sourcery Aarch64 toolchain

2016-05-08T13:05:14+00:00

As noticed by Romain Naour, commit 4d39ca1c2ab19766abf0430abe9b65ba0e16602b ("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 Signed-off-by: Thomas Petazzoni

toolchain-external: remove Sourcery PowerPC toolchains

2016-05-01T13:05:34+00:00

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 Reviewed-by: Romain Naour [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

toolchain-external: bump CodeSourcery MIPS to 2016.06-8

2016-05-01T12:56:06+00:00

Add hash for the toolchain sources. Runtime tested with Qemu with qemu_mips_malta_defconfig Signed-off-by: Romain Naour Signed-off-by: Thomas Petazzoni

toolchain-external: bump CodeSourcery AMD64 to 2015.11-139

2016-05-01T12:46:17+00:00

>From getting-started.pdf: - Linker bug fix. - Fix CVE 2015-7547 getaddrinfo. - Breakpoint in non-existent file bug fix. Signed-off-by: Romain Naour Signed-off-by: Thomas Petazzoni

toolchain-external: bump CodeSourcery NiosII to 2015.11-130

2016-05-01T12:46:06+00:00

>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 Signed-off-by: Thomas Petazzoni

toolchain-external: add GCC 6.x option

2016-05-01T12:41:47+00:00

Commit 519d83bfa0442439026db4e71e605a5c1347e566 adds support for GCC 6. Add an GCC 6.x option for external toolchains, too. Signed-off-by: Jörg Krause Signed-off-by: Thomas Petazzoni