summaryrefslogtreecommitdiffstats
path: root/toolchain
Commit message (Collapse)AuthorAgeFilesLines
* toolchain/helper: don't follow symlinks when copying libs to targetYann E. MORIN2016-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain-external: correct hash value for Linaro AArch64 toolchain sourceClayton Shotwell2016-05-241-1/+1
| | | | | | | | | 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>
* toolchain: improve SSP logicVicente Olivert Riera2016-05-234-6/+40
| | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain-external: fix user provided libraries deploymentRomain Naour2016-05-131-1/+1
| | | | | | | | | | | | | | | | | | | 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 <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: fix registration of hook for Sourcery Aarch64 toolchainThomas Petazzoni2016-05-081-1/+1
| | | | | | | | | | | | 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 <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: remove Sourcery PowerPC toolchainsGustavo Zacarias2016-05-013-65/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain-external: bump CodeSourcery MIPS to 2016.06-8Romain Naour2016-05-013-9/+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>
* toolchain-external: bump CodeSourcery AMD64 to 2015.11-139Romain Naour2016-05-012-3/+3
| | | | | | | | | | >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>
* toolchain-external: bump CodeSourcery NiosII to 2015.11-130Romain Naour2016-05-012-3/+3
| | | | | | | | | | >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>
* toolchain-external: add GCC 6.x optionJörg Krause2016-05-011-0/+4
| | | | | | | | Commit 519d83bfa0442439026db4e71e605a5c1347e566 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>
* toolchain-external: bump version of Linaro AArch64 toolchainThomas Petazzoni2016-04-303-4/+4
| | | | | | | 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>
* toolchain-external: bump version of Linaro ARMeb toolchainThomas Petazzoni2016-04-303-6/+6
| | | | | | 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>
* toolchain-external: bump version of Linaro ARM toolchainThomas Petazzoni2016-04-303-5/+5
| | | | | | | 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>
* toolchain-external: bump CodeSourcery aarch64 to 2014.11Romain Naour2016-04-303-12/+13
| | | | | | | | | | 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>
* toolchain-external: fix installation for CodeSourcery AArch64 toolchainRomain Naour2016-04-301-0/+8
| | | | | | | | | | | | | | | | 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>
* gcc: add support for gcc 6Thomas Petazzoni2016-04-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain/helper: update check_unusable_toolchain commentRomain Naour2016-04-271-3/+6
| | | | | Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: move the sysroot check to helper functionRomain Naour2016-04-272-9/+6
| | | | | | | | | | | | | | | | | | | 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 2a87b64f8e8a832a351f8552eb032e4b18431949. 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>
* toolchain-external: add a check for unsupported toolchainsRomain Naour2016-04-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain-external: remove useless shell continuationsThomas Petazzoni2016-04-251-9/+9
| | | | | | | | | | | 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>
* toolchain-external: rename Blackfin related special variablesThomas Petazzoni2016-04-251-4/+4
| | | | | | | | | | | | | | | | 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>
* toolchain-external: unify LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBSThomas De Schampheleire2016-04-252-13/+12
| | | | | | | | | | | | | | 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>
* toolchain-external: align library locations in target and staging dirThomas De Schampheleire2016-04-252-85/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain-external: extract installation of gdbserver to separate defineThomas De Schampheleire2016-04-251-17/+23
| | | | | | | | | | | | | | | 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>
* toolchain-external: blackfin: install FDPIC libraries also to stagingThomas De Schampheleire2016-04-251-0/+16
| | | | | | | | | | | | | | | 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>
* toolchain-external: remove unused calculation of ARCH_SUBDIRThomas De Schampheleire2016-04-211-7/+1
| | | | | | | | | | | 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>
* toolchain-external: CodeSourcery NiosII 2015.11 affected by PR19405Romain Naour2016-04-202-0/+5
| | | | | | | | | | | | | | | 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>
* arch/x86: remove support for i386Thomas Petazzoni2016-04-182-5/+1
| | | | | | | | | | | | 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>
* toolchain-buildroot: don't show musl on noMMU platformsThomas Petazzoni2016-04-081-0/+3
| | | | | | | | | | | 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>
* toolchain-buildroot: update glibc comment for noMMUThomas Petazzoni2016-04-081-0/+1
| | | | | | | | | 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>
* toolchain-external: fix getent installation with Codescape MIPS toolchainsThomas Petazzoni2016-03-301-0/+22
| | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain: introduce BR2_TOOLCHAIN_HAS_LIBATOMICThomas Petazzoni2016-03-201-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.]
* toolchain/external: add hashes for actual sourcesYann E. MORIN2016-03-191-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain: add 4.5.x choice for headersGustavo Zacarias2016-03-142-0/+9
| | | | | Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: switch linaro to https urlsJason Abele2016-03-091-6/+6
| | | | | | 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>
* toolchain: also source the musl packageYann E. MORIN2016-03-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain: bump Codescape toolchains to version 2015.10Vicente Olivert Riera2016-03-083-34/+73
| | | | | Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: bump musl toolchain to 1.1.12Thomas Petazzoni2016-03-053-24/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'next'Peter Korsgaard2016-03-021-3/+2
|\ | | | | | | Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
| * glibc: remove version 2.21Gustavo Zacarias2016-02-291-3/+2
| | | | | | | | | | | | | | 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>
* | toolchain-external/Config.in: Fix Linaro typoPeter Korsgaard2016-02-211-2/+2
|/ | | | Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: add BR2_TOOLCHAIN_HAS_{SYNC_x, ATOMIC} hidden booleansThomas Petazzoni2016-02-061-0/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain/external: newer Linaro toolchains do not provide source codeYann E. MORIN2016-02-031-3/+3
| | | | | | | | | | | | | | | | 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>
* toolchain: copy_toolchain_lib_root: rename LIBSPATH to LIBPATHSThomas De Schampheleire2016-02-031-3/+3
| | | | | | | | | | | | | | | | 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>
* toolchain-external: bump Linaro ARMEB to 2015.11-2Romain Naour2016-02-013-5/+5
| | | | | | | 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>
* toolchain-external: bump Linaro ARM to 2015.11-2Romain Naour2016-02-013-5/+5
| | | | | | | | | | | | Runtime tested with Qemu 2.3.1 using a configuration based on qemu_arm_vexpress_defconfig with BR2_ARM_ENABLE_VFP and BR2_ARM_EABIHF selected 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. This has been runtime tested in Qemu.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: bump Linaro AArch64 to 2015.11-2Romain Naour2016-02-013-5/+5
| | | | | | | | | | Runtime tested with Qemu 2.3.1 using qemu_aarch64_virt_defconfig. 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. This has been runtime tested in Qemu.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: create symlink ARCH_LIB_DIR->libThomas De Schampheleire2016-02-011-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, following symbolic links are created in both target and staging directories: - lib(32|64) --> lib - usr/lib(32|64) --> lib The decision for lib32 or lib64 is based on the target architecture configuration in buildroot (BR2_ARCH_IS_64). In at least one case this is not correct: when building for a Cavium Octeon III processor using the toolchain from the Cavium Networks SDK, and specifying -march=octeon3 in BR2_TARGET_OPTIMIZATION, libraries are expected in directory 'lib32-fp' rather than 'lib32' (ABI=n32; likewise for lib64-fp in case of ABI=n64) More generally the correct symbolic link is from (usr/)${ARCH_LIB_DIR}->lib. However, feedback from Arnout Vandecappelle is that there are packages that do depend on the lib32/lib64 symlink, even if ARCH_LIB_DIR is different. Hence, these links must be kept. Fix the problem as follows: - For internal toolchains: no change - For external toolchains: create a symlink ARCH_LIB_DIR->lib if (usr/)ARCH_LIB_DIR does not exist yet. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: "Yann E. Morin" <yann.morin.1998@free.fr> Cc: Romain Naour <romain.naour@gmail.com> Cc: Peter Korsgaard <peter@korsgaard.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>
* toolchain-external: improve sysroot rsync if ARCH_LIB_DIR != lib/lib32/lib64Thomas De Schampheleire2016-02-011-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The copy_toolchain_sysroot helper in toolchain/helpers.mk performs an rsync of various directories from the extracted external toolchain to the corresponding directory in staging. The relevant (simplified) snippet is: for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \ rsync -au --chmod=u=rwX,go=rX --exclude 'usr/lib/locale' \ --exclude '/lib/' --exclude '/lib32/' \ --exclude '/lib64/' \ $${ARCH_SYSROOT_DIR}/$$i/ $(STAGING_DIR)/$$i/ ; \ done ; \ The exclusion logic of lib/lib32/lib64 has originally been added by commit 5628776c4a4d29d0715633ea463b64cc19e19c5a with the purpose of only copying the relevant usr/lib* directory from the toolchain to staging, instead of all. For example, if ARCH_LIB_DIR is 'lib64', then only usr/lib64 would be copied and usr/lib and usr/lib32 are ignored. It works by ignoring any lib/lib32/lib64 subdirectory on the rsync of 'usr' and then separately copying usr/{lib,lib32,lib64} as appropriate. (The exclusion rules only have impact on the files beneath the main source directory.) However, ARCH_LIB_DIR can take other values than (lib, lib32, lib64), for example lib32-fp or lib64-fp (Octeon III toolchain with -march=octeon3). In the existing code, the rsync for 'usr' would then already copy these lib directories, and the next rsync for 'usr/$${ARCH_LIB_DIR}' does nothing. By itself, this is not a very big problem: the staging directory simply has some extra directories. However, a subsequent patch will create a staging symlink from $${ARCH_LIB_DIR} to lib. The first rsync would then overwrite that symlink with the real directory usr/$${ARCH_LIB_DIR} from the toolchain, which is not correct. Assuming the patch that creates the symlink ARCH_LIB_DIR->lib is applied, the original situation after 'make clean toolchain' with an ARCH_LIB_DIR=lib32-fp is: $ ls -ld output/staging/{,usr/}lib* output/target/{usr/,}lib* drwxr-xr-x 2 4096 May 26 2015 output/staging/lib lrwxrwxrwx 1 3 Jan 20 13:47 output/staging/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 13:47 output/staging/lib32-fp -> lib drwxr-xr-x 2 4096 Jan 20 13:47 output/staging/usr/lib lrwxrwxrwx 1 3 Jan 20 13:47 output/staging/usr/lib32 -> lib drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/lib32-fp drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/lib64-fp drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/libexec drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec32 drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec32-fp drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec64-fp drwxr-xr-x 2 4096 Jan 20 13:48 output/target/lib lrwxrwxrwx 1 3 Jan 20 13:47 output/target/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 13:47 output/target/lib32-fp -> lib drwxr-xr-x 2 4096 Jan 20 13:48 output/target/usr/lib lrwxrwxrwx 1 3 Jan 20 13:47 output/target/usr/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 13:47 output/target/usr/lib32-fp -> lib Notice how usr/lib32-fp is not a symlink but a directory, and the presence of an unnecessary directory usr/lib64-fp. This patch improves the rsync exclusion rules by excluding any lib* directory on the first rsync. As this would also exclude any libexec/libexec32/... directory, explicitly include them first (first match takes precedence). This (as is already the case today) results in more usr/libexec* directories than needed, but it is not touched by this patch. With the fix applied, the situation becomes: drwxr-xr-x 2 4096 May 26 2015 output/staging/lib lrwxrwxrwx 1 3 Jan 20 14:27 output/staging/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 14:27 output/staging/lib32-fp -> lib drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/lib lrwxrwxrwx 1 3 Jan 20 14:27 output/staging/usr/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 14:27 output/staging/usr/lib32-fp -> lib drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/libexec drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec32 drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec32-fp drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec64-fp drwxr-xr-x 2 4096 Jan 20 14:27 output/target/lib lrwxrwxrwx 1 3 Jan 20 14:27 output/target/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 14:27 output/target/lib32-fp -> lib drwxr-xr-x 2 4096 Jan 20 14:27 output/target/usr/lib lrwxrwxrwx 1 3 Jan 20 14:27 output/target/usr/lib32 -> lib lrwxrwxrwx 1 3 Jan 20 14:27 output/target/usr/lib32-fp -> lib For cases where ARCH_LIB_DIR is one of lib, lib32 or lib64 this fix makes no difference, and likewise for internal toolchains. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: don't exclude too much lib in sysroot rsyncThomas De Schampheleire2016-02-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The copy_toolchain_sysroot helper in toolchain/helpers.mk performs an rsync of various directories from the extracted external toolchain to the corresponding directory in staging. The relevant (simplified) snippet is: for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \ rsync -au --chmod=u=rwX,go=rX --exclude 'usr/lib/locale' \ --exclude lib --exclude lib32 --exclude lib64 \ $${ARCH_SYSROOT_DIR}/$$i/ $(STAGING_DIR)/$$i/ ; \ done ; \ The exclusion logic of lib/lib32/lib64 has been added by commit 5628776c4a4d29d0715633ea463b64cc19e19c5a with the purpose of only copying the relevant usr/lib* directory from the toolchain to staging, instead of all. For example, if ARCH_LIB_DIR is 'lib64', then only usr/lib64 would be copied and usr/lib and usr/lib32 are ignored. It works by ignoring any lib/lib32/lib64 subdirectory on the rsync of 'usr' and then separately copying usr/{lib,lib32,lib64} as appropriate. (The exclusion rules only have impact on the files beneath the main source directory.) However, on the rsync of 'usr', ANY of the following directories AND files would be excluded: lib/ lib lib32/ foobar/something/lib/ something-else/lib64/ while it is only the intention to skip directories directly under usr. Therefore, add a leading (to restrict the scope to first-level) and trailing (to restrict to directories) slash to the exclude pattern. From 'man rsync': - if the pattern starts with a / then it is anchored to [..] the root of the transfer. - if the pattern ends with a / then it will only match a directory, not a regular file, symlink, or device. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
OpenPOWER on IntegriCloud