aboutsummaryrefslogtreecommitdiff
path: root/toolchain/helpers.mk
Commit message (Collapse)AuthorAgeFilesLines
* toolchain/external: better report RPC error for custom toolchainsGravatar Yann E. MORIN2015-05-051-2/+2
| | | | | | | | | | | | | | | | | | Currently, we instruct users to enable/disable BR2_TOOLCHAIN_HAS_NATIVE_RPC but that is a blind option. The only option users can set/unset is BR2_TOOLCHAIN_EXTERNAL_INET_RPC. Use that in the error message. Notes: the only way for this message to appear is for a custom external toolchain, either downloaded or pre-installed, so even though we check the validity of the toolchain with BR2_TOOLCHAIN_HAS_NATIVE_RPC, we do report on BR2_TOOLCHAIN_EXTERNAL_INET_RPC. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: make IPv6 mandatory for external toolchainsGravatar Gustavo Zacarias2015-04-221-1/+1
| | | | | | | | | | | | Remove BR2_INET_IPV6 select for predefined external toolchains. Remove the (non)IPv6 option prompt since it's now mandatory. And force the toolchain check now that internal uclibc is always built with IPv6 support and external non-IPv6 toolchains are disallowed. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/external: do not accept distro-class toolchainsGravatar Yann E. MORIN2015-04-041-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | Distro toolchains, i.ie. toolchains coing with distributions, will almost invariably be unsuitable for use with Buildroot: - they are mostly non-relocatable; - their sysroot is tainted with a lot of extra libraries. Especially, the toolchains coming with Ubuntu (really, all the Debian familly of distros) are configured with --sysroot=/ which makes them non-relocatable, and they already contain quite some libraries that conflict (in any combination of version, API or ABI) with what Buildroot wants to build (i.e. extra libraries, some not even present in Buildroot...) but also their mere preence when Buildroot does not expect them to be already built (so that a package would enable features when it should not). So, try to detect those toolchains and black-list them; inform the user that the toolchain is unusable for the reasons mentioned above. 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> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/helpers: make LFS mandatory for uclibc toolchainsGravatar Gustavo Zacarias2015-04-011-1/+1
| | | | | | | | | | As discussed on the mailing list drop the non-largefile option for toolchains. The size delta is minimal and it just complicates package dependencies. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/helpers: add check for mandatory uClibc optionsGravatar Gustavo Zacarias2015-04-011-7/+17
| | | | | | | | | | | | | | | | | | | | | | | | We currently only check that the Buildroot configuration matches what is available in the toolchain. Since we're going to remove the check for LFS and make it a mandatory feature, we will lose the corresponding buildroot option, so we won't be able to use check_uclibc_feature as-is. Introduce a magic value passed as the buildroot option name to recognise checks for mandatory uclibc options that do not have a corresponding option in buildroot. If the buildroot option name is empty then the check is against a mandatory uclibc option. If a mandatory uclibc option is missing we reject the toolchain as being unusable by buildroot. [Thomas: minor tweaks in comment, remove space instead of tab.] Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* package: indentation cleanupGravatar Jerzy Grzegorek2014-10-231-2/+2
| | | | | Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/helpers.mk: update check_arm_abi commentGravatar Baruch Siach2014-07-041-0/+1
| | | | | | | | | | | Since commit b2e88073dbf (toolchain: check ARM EABI vs. EABIhf for external toolchains), check_arm_abi accepts a second parameter. Update the comment accordingly. Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain/helpers.mk: don't discard check_arm_abi stderrGravatar Baruch Siach2014-07-041-1/+1
| | | | | | | | | | | | Since we only need to know whether the compiler runs successfully, and stderr is empty for the success case, there is no need to redirect stderr to /dev/null. Moreover, stderr output of the failing case reveals valuable information on the real failure reason. Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-external: Fix EABIhf checkGravatar Stefan Sørensen2014-05-111-12/+4
| | | | | | | | | | | | | | | | | | | | | | | | Currently the check for EABI/EABIhf toolchains looks for the Tag_ABI_VFP_args attribute in the crt1.o file which gcc adds in an EABIhf toolchain. In uClibc, however, crt1.o is not compiled from c but assembly, so the Tag_ABI_VFP_args attribute is not added in the object file. This causes the EABIhf check in the external toolchain logic to fail for uClibc-based toolchains. Fix by compiling a dummy .c file and trying to link the object against the C library. Since it is impossible to mix EABI and EABIhf code, a mismatch between the buildroot and toolchain ABI settings will be detected during this link step. Fixes bug #6842: https://bugs.busybox.net/show_bug.cgi?id=6842 [Peter: fix final 'fi'] Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> [ThomasDS: do full link iso readelf test, update commit message] Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: generate a gdbinit fileGravatar Thomas Petazzoni2014-05-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | This commit slightly improves the external toolchain backend, and the gdb build logic to create a file named $(STAGING_DIR)/usr/share/buildroot/gdbinit which can be used as a gdbinit file using gdb -x option. This allows gdb to automatically use the proper sysroot to find libraries. The initial insight for this patch comes from the report of Oded Hanson <OHanson@xsightsys.com>, who found an issue with the Eclipse Buildroot plugin, which was setting a solib-path in gdb, but not a sysroot. Setting a solib-path was enough to find shared libraries, but not the dynamic linker. And since Eclipse doesn't allow to set the sysroot in any other way than giving a gdbinit file, it makes sense to have Buildroot generate a gdbinit file (which can be used in other situations than Eclipse). To achieve this, this commit introduces a gen_gdbinit_file helper in toolchain/helpers.mk, and uses it for the internal toolchain and external toolchain backends. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [ThomasDS: minor updates in commit message] Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* support/check-kernel-headers: fix old custom toolchains without -print-sysrootGravatar Yann E. MORIN2014-04-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Old toolchains, with old gcc that do not support -print-sysroot, break the kernel-headers version check script: it fails to find the sysroot of the toolchain, and thus ends up including the host's linux/version.h. Most of the time, this will break early, since the host's kernel headers will not match the toolchain settings. But it can happen that the check is succesful, although the configuration of the toolchain is wrong: - the custom toolchain has kernel headers vX.Y - the user selected vX.Z (Z!=Y) - the host has headers vX.Y In this case, the check passes OK, but the build of some packages later on will break (which is exactly what those _AT_LEAST_XXX options were added to avoid). Fix that by passing the sysroot to the check script, instead of the cross compiler. We get the sysroot as thus: - for custom toolchains, we use the macro toolchain_find_sysroot. We can do that, because we already have a complete sysroot with libc.a at that time. - for internal toolchain using a custom kernel headers version, we just use $(STAGING_DIR). We can't use the macro as for custom toolchains above, because at the time we install the kernel headers, we do not yet have a complete sysroot with a libc.a. But we can just use $(STAGING_DIR), since we're only interested in the kernel headers. For all other types of toolchains, we already have the _AT_LEAST_XXX options properly set, so we need not add a check in this case. Fixes: http://autobuild.buildroot.net/results/f33/f331a6eff0b0b93c73af52db3a6b43e4e598577e/ http://autobuild.buildroot.net/results/a57/a5797c025bec50c10efdcff74945aab4021d05e4/ [...] [Thanks to Thomas for pointing out the toolchain_find_sysroot macro!] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: print actual version of kernel headers when checkingGravatar Yann E. MORIN2014-04-061-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we introduced the _AT_LEAST_XXX for the kernel headers, people using pre-built custom toolchain now have to specify the version of the kernel headers their custom toolchain uses. So, when we detect that there is a mismatch between the selection in the menuconfig, and the actual version of the headers, we currently only bail out with a terse message "Incorrect selection of kernel headers". This could be confusing some, and getting the version of the headers used by the toolchain is not trivial (well, it's very easy, but not trivial.) This patch changes the way we report the error by moving the message into the test-code, and by printing the expected and actual versions of the kernel headers. BUT! To get this pretty error message, we need to run the test-program, so we can not use the cross-toolchain, we have to use the native one. BUT! The native one has its own linux/version.h header, so we can not simply include it. So, we ask the cross-compiler where its default sysroot is, and use that to then force-feed the cross linux/version.h to the native toolchain. [Thomas: augment commit log with a message provided by Yann, fix coding style to not have spaces after opening parenthesis and before closing parenthesis, reformatted the message "Incorrect selection..." to make it fit on one line.] Reported-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/external: check kernel headers version for custom toolchainGravatar Yann E. MORIN2014-03-011-0/+13
| | | | | | | | | | | | | | | | | | Ensure the kernel headers version used in the custom external toolchain, or the manually-specified kernel headers version, matches exactly the one selected by the user. We do not care about the patch-level, since headers are not supposed to change between patchlevels. This applies only to kernels >= 3.0, but those are actually the ones we do care about; we treat all 2.6.x kernels as being a single version, since we do not support any 2.6 kernels for packages with kernel-dependant features. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: introduce a toolchain knob for NPTLGravatar Thomas Petazzoni2014-02-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | As our architecture support expands to a number of architectures that do not implement NPTL threading, and the number of packages that depend on NPTL specific features, it has become necessary to be able to know whether the toolchain has NPTL support or not. This commit adds a new BR2_TOOLCHAIN_HAS_THREADS_NPTL hidden Config.in option that allows packages to know whether NPTL is available or not. This hidden option is: * Automatically enabled when glibc/eglibc or musl toolchains are used, either internal or external. * Automatically enabled when an internal uClibc toolchain with NPTL support is configured. It is left disabled otherwise for internal uClibc toolchains. * Configured according to a visible Config.in option for custom external uClibc toolchains. [Peter: factor _EXTERNAL_HAS_THREADS in single if as suggested by Arnout] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: Allow ld64.so linkerGravatar Jeremy Kerr2013-12-031-1/+1
| | | | | | | | | | The glibc dynamic linkers for ppc64 and s390x are named ld64.so.* so modify the check_glibc test to match them. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Anton Blanchard <anton@samba.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-external: add a specific check to avoid Angstrom toolchainsGravatar Thomas Petazzoni2013-10-141-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | The Angstrom toolchains available at http://www.angstrom-distribution.org/toolchains/ are not usable as external toolchains in Buildroot, because they are not pure toolchains with just the C library, but instead complete SDKs with many cross-compiled libraries (Gtk, Qt, glib, neon, sqlite, X.org, and many more, approximately 200 MB of libraries). Buildroot cannot use such toolchains, and while this is documented in our manual, some users still try to do this. Today, one such user came on the IRC channel, reporting a build problem, which we started investigating, only to realize after a long time that he was using an Angstrom toolchain. To avoid this problem in the future, we explicitly check if the toolchain is from Angstrom by looking at the vendor part of the tuple exposed by the toolchain: as soon as it is <something>-angstrom-<something-else>, we reject the toolchain with an explanation. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-external: improve target library copy logicGravatar Thomas Petazzoni2013-10-091-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The copy_toolchain_lib_root function is responsible for copying a given library (and its symbolic link) to the target filesystem. To do so, it looks for the library in various locations, and then iterates over the symbolic link all the way to the library, copying them as needed to the target filesystem. However, the latest Linaro toolchains bring an interesting use case: the lib/ directory in the toolchain is organized as follows: - ld-linux.so.3 -> arm-linux-gnueabi/ld-2.17...so - ld-linux-armhf.so.3 -> arm-linux-gnueabihf/ld-2.17...so - arm-linux-gnueabi/ - all ARMv4T soft float libraries - arm-linux-gnueabihf/ - all ARMv7 hard float libraries In order to match what we do with all other toolchains, we want all those libraries and symbolic links to be copied directly under $(TARGET_DIR)/lib. This commit does that by adjusting the copy logic. This is part of the fix for bug #6452 (eglibc from Linaro 2013.07 not copied to target correctly). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-external: add support for musl C libraryGravatar Thomas Petazzoni2013-10-091-0/+11
| | | | | | | | | | | | | | | | | | This commit adds support for external toolchains based on the musl C library, as available from http://www.musl-libc.org. Note that the pre-built musl toolchains available from http://musl.codu.org/ are not working for the moment, since they lack sysroot support. However, this problem has been reported to the maintainer, who has already added sysroot support in his scripts at https://bitbucket.org/GregorR/musl-cross, and therefore the next version of the pre-built toolchains should work with Buildroot out-of-the-box. In the mean time, the musl-cross script must be used to build the toolchain. [Peter: reword comment] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: do not check largefile, wchar, IPv6 and locale for glibc toolchainsGravatar Thomas Petazzoni2013-10-091-4/+0
| | | | | | | | | | | | | | The check_glibc function contained checks to verify that the user had properly enabled the largefile, IPv6, locale and wchar options, to match how glibc is configured. This was useful when the support for glibc external toolchains was introduced, but since then, we added the BR2_TOOLCHAIN_USES_GLIBC symbol that automatically enables largefile, IPv6, locale and wchar support when a glibc or eglibc external toolchain is used. Therefore, many of the check_glibc checks are useless now, so we can remove these. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: fix the helpers.mk commentGravatar Thomas Petazzoni2013-10-091-6/+7
| | | | | | | | | | | | | | | | | | | | This commit fixes various typos and mistakes in the comment at the top of the helpers.mk file: * usefull -> useful * The optional stripping of libraries no longer exists, so there's no reason to mention it. * Indicate that the copy_toolchain_lib_root function is also used by the glibc package, not only by the external toolchain logic. * Separate more clearly the top comment introducing the entire file, from the comment introducing the first function. [Peter: reword top comment, add missing 'by'] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: modify the wildcard logic for shared libraries copyingGravatar Thomas Petazzoni2013-10-091-1/+1
| | | | | | | | | | | | | | | | | Until now, the copy_toolchain_lib_root function took as argument the base name of a library (e.g: libm.so), and was assuming that the usual scheme libm.so.<x> being a symbolic link to the real library was used. However, with musl based toolchains, the C library is named libc.so directly, with no symbolic link at all. Therefore, this commit changes the copy_toolchain_lib_root to move the responsibility of using a wildcard or not after the library name the caller's responsibility. So, all the existing LIB_EXTERNAL_LIBS values are modified to have a .* at the end, so that the behavior is effectively unchanged. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-crosstool-ng: remove supportGravatar Thomas Petazzoni2013-10-061-3/+1
| | | | | | | | | | In order to avoid the work of converting the toolchain-crosstool-ng logic to the package infrastructure, we remove it from Buildroot, since it has been deprecated since quite some time. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: refactor Stack Smashing Protection supportGravatar Thomas Petazzoni2013-09-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This commit refactors how Stack Smashing Protection support is handled in Buildroot: *) It turns the BR2_TOOLCHAIN_BUILDROOT_USE_SSP option into an option that only enables the SSP support in uClibc, when using the internal toolchain backend. *) It adds an hidden BR2_TOOLCHAIN_HAS_SSP option that gets enabled when the toolchain has SSP support. Here we have the usual dance: glibc/eglibc in internal/external backend always select this option, in the case of uClibc/internal, it gets selected when BR2_TOOLCHAIN_BUILDROOT_USE_SSP is enabled, in the case of uClibc/external, there is a new configuration option that the user must select (or not) depending on whether the toolchain has SSP support. *) It adds a new options BR2_ENABLE_SSP in the "Build options" menu, to enable the usage of SSP support, by adding -fstack-protector-all to the CFLAGS. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain-external: fix lib64 symlinksGravatar Samuel Martin2013-08-271-16/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Always link lib64 or lib32 to lib * Only copy the architecture's lib directory to staging * Also cleanup a couple of mkdirs (concerning some 'lib' directories). Before this patch: $ ls -ld host/usr/x86_64-buildroot-linux-gnu/sysroot/{,usr/}lib* target/{usr/,}lib* drwxr-xr-x 2 samuel users 4.0K Aug 12 22:26 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64/ drwxr-xr-x 5 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/ drwxr-xr-x 5 samuel users 4.0K Aug 12 22:27 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/ drwxr-xr-x 3 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/libexec/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 target/lib/ lrwxrwxrwx 1 samuel users 3 Aug 12 22:27 target/lib64 -> lib/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 target/usr/lib/ lrwxrwxrwx 1 samuel users 3 Aug 12 22:27 target/usr/lib64 -> lib/ $ find . -type l -xtype l # find broken symlinks find: `./host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64/lib': Too many levels of symbolic links find: `./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/lib': Too many levels of symbolic links ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_files.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_nis.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_compat.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_nisplus.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libutil.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libthread_db.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libcidn.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libcrypt.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libm.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_hesiod.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnsl.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/librt.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_db.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libanl.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libBrokenLocale.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_dns.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libresolv.so ./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libdl.so ./target/etc/resolv.conf ./target/dev/log After this patch: $ ls -ld host/usr/x86_64-buildroot-linux-gnu/sysroot/{,usr/}lib* target/{usr/,}lib* drwxr-xr-x 2 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib/ lrwxrwxrwx 1 samuel users 5 Aug 12 22:36 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64 -> lib/ drwxr-xr-x 5 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/ lrwxrwxrwx 1 samuel users 5 Aug 12 22:36 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64 -> lib/ drwxr-xr-x 3 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/libexec/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:36 target/lib/ lrwxrwxrwx 1 samuel users 3 Aug 12 22:36 target/lib64 -> lib/ drwxr-xr-x 2 samuel users 4.0K Aug 12 22:36 target/usr/lib/ lrwxrwxrwx 1 samuel users 3 Aug 12 22:36 target/usr/lib64 -> lib/ $ find . -type l -xtype l # find broken symlinks ./target/etc/resolv.conf ./target/dev/log Fixes http://autobuild.buildroot.net/results/23fb6b1479d2b5906b72c9437b06ab4700ff246d/ Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: check ARM EABI vs. EABIhf for external toolchainsGravatar Thomas Petazzoni2013-07-181-0/+15
| | | | | | | | | | | | | | | | | | | | Following the introduction of the support of EABIhf as a second ARM ABI, it is important to check whether the external toolchain provided by the user actually uses the ABI that has been selected in the Buildroot configuration. This commit introduces such a check by looking at the 'Tag_ABI_VFP_args' tag of the architecture-specific section of the ELF headers. This assumes that ELF is the binary format used on ARM, which may not be the case on ARM noMMU systems (they use the FLAT binary format), but Buildroot doesn't have support for such systems at the moment. Also ensure the correct CFLAGS are passed to the cross compiler for the test, so the correct variant is used in case the toolchain is multilib. [Peter: mention CFLAGS change] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain/helpers: don't use the x$(...) = x"value" syntaxGravatar Thomas Petazzoni2013-07-171-3/+3
| | | | | | | | | | As noted by Yann E. Morin, the x$(...) = x"value" syntax is old and ugly, and the easier to read "$(...)" = "value" can now be used without problems. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain/helpers: only check for an EABI toolchainGravatar Yann E. MORIN2013-07-141-7/+2
| | | | | | | | | ... since we only support EABI now. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain/helpers: ARM OABI is no longer supportedGravatar Yann E. MORIN2013-07-141-4/+0
| | | | | | | Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain-external: improve glibc support to test availability of RPCGravatar Thomas Petazzoni2012-11-041-5/+22
| | | | | | | | | | | | | | | | | Basically, the BR2_TOOLCHAIN_EXTERNAL_GLIBC option no longer unconditionally selects BR2_TOOLCHAIN_HAS_NATIVE_RPC since there are glibc toolchains that don't have RPC support. All the predefined toolchain profiles are updated to take into account this change: for the moment, all glibc toolchains that have pre-defined toolchains have RPC support, but further patches in the series add pre-defined glibc toolchains that don't have RPC support. In the case of custom glibc toolchains, a question is asked to the user so that he can say whether the external glibc toolchain has RPC support or not. The validity of this configuration option is checked by the new check_glibc_rpc_feature function in helpers.mk. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Rename BR2_INET_RPC to BR2_TOOLCHAIN_HAS_NATIVE_RPCGravatar Thomas Petazzoni2012-11-041-2/+2
| | | | | | | | | | The BR2_INET_RPC has for a long time been a not very descriptive configuration option name, and with the advent of non-RPC glibc toolchains and the apparition of libtirpc, we really need to rename it to something more sensible, BR2_TOOLCHAIN_HAS_NATIVE_RPC. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: have check_glibc to search deeper for ld-linuxGravatar Jean-Mickael Guerin2012-10-201-1/+1
| | | | | | | | | | | | ld-linux*.so may not be present in lib/ directory, it could be in lib32 and/or lib64 only. But check_glibc reports "Incorrect selection of the C library" in this case, which is not true. Fixed by extending the search to SYSROOT/*/*. Signed-off-by: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain/helpers.mk: fix check_glibc sysroot typoGravatar Peter Korsgaard2012-08-311-1/+1
| | | | | | | Introduced by 68973cca2 (adjust logic to support Linaro 2012.05) Reported-by: R Zhong <rzhong@hotmail.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain-external: adjust logic to support Linaro 2012.05Gravatar Thomas Petazzoni2012-07-221-2/+2
| | | | | | | | | | | | | | | | | | | | | The check_glibc function verifies that the C library of the external toolchain is glibc. To do so, it verified that a file matching ld-linux*.so.* or ld.so.* was found in the lib/ directory of the toolchain's sysroot. However, with the Linaro 2012.05 toolchain, the lib/ directory contains two links named ld-linux-armhf.so.3 and ld-linux.so.3, which means that the first ld-linux*.so.* wildcard expression expands to two files, which generates a syntax error for the "test" program. We replace that with a more elaborate find+wc combination to determine whether at least one matching file is present. The check_arm_abi function verifies the ABI of an ARM toolchain. For EABI, it tested that the target name ends with eabi. However, with Linaro 2012.05, the tuple is now arm-linux-gnueabihf (for hard float), so we have to adjust the logic to accept this additional "hf" specification in the tuple. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external-toolchain: add support for recent Linaro toolchainsGravatar Thomas Petazzoni2012-05-071-24/+49
| | | | | | | | | | | | | | Starting from 2012.03, the Linaro toolchains have separated the GCC support libraries (libstdc++, libgcc_s) from the sysroot itself. So we no longer have the case where all libraries are inside the sysroot, as we had for all the previously supported toolchains. Therefore, we add some logic to detect if such a separate directory is used for GCC support libraries, and if it's the case, we make sure that we take into account this directory when creating our own sysroot, and when copying libraries to the target filesystem. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external-toolchain: add support for Linaro 2012.01Gravatar Thomas Petazzoni2012-03-011-6/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linaro has just released a new pre-built toolchain, available as a tarball, which is a pure toolchain (only the C library is included). This makes this new Linaro 2012.01 toolchain usable in Buildroot, so let's integrate the support for it. In addition to simply adding the new external toolchain at the usual locations, this patch allows need to adapt a few things to support Linaro toolchains. Most toolchains store their libraries in the "lib/" or "usr/lib" directories relative to the toolchain. Buildroot toolchains on the other hand, store the libraries in the "usr/<target-name>/lib" directory. And the Linaro toolchain has choosen to use the "lib/<target-name>" directory. Therefore, this patch adjust: * The logic to search a particular library when that library needs to be copied to the target directory * The logic to deduce the sysroot directory from the libc.a file location in the toolchain: removing "(usr/?)lib(64?)" is no longer sufficient, we need to take into account the "lib/<target-name>/" case. Since the Linaro toolchain generates code for Cortex-A processors only, the selection of this toolchain is limited to Cortex-A8 and Cortex-A9. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external-toolchain: adjust check for uClibc static toolchainsGravatar Thomas Petazzoni2012-03-011-1/+1
| | | | | | | | | The current check for uClibc toolchain was verifying that a ld-uClibc.so dynamic loader was present. However, with static-only uClibc toolchains, this does not work. Instead, we check for an uClibc-specific header file in the sysroot. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Support multilib variants in sub-subdirectoriesGravatar Thomas Petazzoni2012-03-011-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an external toolchain has multiple variants organized in sub-directories, Buildroot only copies the selected sysroot and not all sysroots. In order to make this work, Buildroot creates a symbolic link of the name of the original selected sysroot to the main sysroot to trick the compiler so that it finds its libraries at the expected location. I.e, if the toolchain as the following organization (example take on the ARM CodeSourcery toolchain) : . for ARMv5T armv4 for ARMv4T thumb2 for ARMv7-A/Thumb and ARMv4T is selected, then Buildroot will copy the contents of armv4t/ from the toolchain into its $(STAGING_DIR) and then create a $(STAGING_DIR)/armv4t symbolic link to $(STAGING_DIR). However, our logic to do so only works when there was one directory level for multilib sysroots. But in the MIPS CodeSourcery toolchain there are multiple levels. For example, the MIPS16 soft-float little-endian sysroot variant is in mips16/soft-float/el/ compared to the main sysroot. This patch improves our logic to support this case. The logic is a bit more complicated as we don't want to create a symbolic link to an absolute path, but a symbolic link to a relative path, because we want the host/ directory to be relocatable. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Improve external toolchain logic to support IA32 Sourcery CodeBench toolchainGravatar Thomas Petazzoni2012-03-011-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The IA32 Sourcery CodeBench toolchain has a relatively special structure, with the following multilib variants: * Intel Pentium 4, 32 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Xeon Nocona, 64 bits, the multilib variant is in ./ relative to the main sysroot, with the libraries in the lib64/ directory. * Intel Atom 32 bits, the multilib variant is in atom/ relative to the main sysroot, with the libraries in the lib/ directory. * Intel Core 2 64 bits, the multilib variant is in core2/ relative to the main sysroot, with the libraries in lib64/ directory. So the first two variants are in the same sysroot, only the name of the directory for the libraries is different. Therefore, we introduce a new ARCH_LIB_DIR variable, which contains either 'lib' or 'lib64'. This variable is defined according to the location of the libc.a file for the selected multilib variant, and is then used when copying the libraries to the target and to the staging directory. In addition to this, we no longer use the -print-multi-directory to get the ARCH_SUBDIR, since in the case of the 64 bits variants of this toolchain, it returns just '64' and not a real path. Instead, we simply compute the difference between the arch-specific sysroot and the main sysroot. We also take that opportunity to expand the documentation on the meaning of the different variables. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gdb: fix kconfig dependency handling with !BR_TOOLCHAIN_BUILDROOTGravatar Peter Korsgaard2011-11-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Newer versions of GDB need pthread debugging support if threads are enabled, which is always the case for glibc but is a configure option for uClibc. We have solved this for internal toolchains by selecting the BR2_PTHREAD_DEBUG option from the GDB selection if needed, but as this option isn't available when ctng/external toolchains are used, mconf prints ugly warnings and the build may fail if an external uClibc toolchain without pthread debugging support is used. Fix it by introducing 2 more hidden config options: - BR2_TOOLCHAIN_HAS_THREADS_DEBUG - BR2_TOOLCHAIN_HAS_THREADS_DEBUG_IF_NEEDED The first tells us if the toolchain HAS pthreads debugging support, and is checked by check_uclibc_feature in helper.mk for external uClibc based toolchains. The second tells us if the toolchain is ABLE TO provide pthreads debugging support if threads are enabled, either because it's an internal toolchain where we can force enable it or an external glibc/eglibc toolchain or uClibc with the option enabled. Crosstool-ng forcibly enables this support, so those will always work. The preconfigured uClibc-based toolchains we have also all enable it. Finally, show a comment if this isn't the case so the (external toolchain) user knows why. This is placed outside the choice option, as menuconfig has a bug where it doesn't show choice selections which only contain comments. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* ext-toolchain: fix ct-ng as external rsync issuesGravatar Gustavo Zacarias2011-11-021-1/+1
| | | | | | | | | | | When using a CT-NG toolchain as external toolchain (not with the integration) and said toolchain has u-w directories rsync fails. So instruct rsync to chmod u+w directories in the target copy to avoid the issue. [Peter: notice that this is a workaround for a rsync 3.0.8 bug] Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: speed up sysroot lib copyingGravatar Mike Frysinger2011-10-101-3/+2
| | | | | | | | | | | | | | | | The copy_toolchain_lib_root helper searches the entire sysroot, but is only interested in files in certain subdirs. So rather than waste time in walking the entire tree, walk the few subdirs at the depth level we are actually going to be poaching files from. Some simplification suggested by Yann E. MORIN <yann.morin.1998@anciens.enib.fr> and Arnout Vandecappelle <arnout@mind.be>, added by Thomas Petazzoni <thomas.petazzoni@free-electrons.com>. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* external toolchain: slightly optimize the copy of the toolchain sysrootGravatar Thomas Petazzoni2011-10-091-1/+4
| | | | | | | | | | | | The sysroot of an ARM CodeSourcery toolchain takes about 1.4 GB of space, but 1.1+ GB of this space consists in locale-related information which Buildroot doesn't use. By skipping the copy of those unused files, we save quite a bit of time while importing the toolchain sysroot. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain/helpers.mk: unbreak check_glibc after PROGRAM_INVOCATION removalGravatar Peter Korsgaard2011-07-291-1/+1
| | | | | | As noticed by Thomas Petazzoni on IRC. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* uClibc: drop BR2_PROGRAM_INVOCATION optionGravatar Peter Korsgaard2011-07-271-2/+0
| | | | | | | | | | | | Remove the BR option and enable the configuration setting in the uClibc defconfigs. The BR2_PROGRAM_INVOCATION option only adds very little overhead to uClibc, and we have a number of packages needing it, so simply always enable it - Simplifying the kconfig logic and the number of choices users have to make. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* external-toolchain: fix supportGravatar Thomas Petazzoni2011-05-081-4/+13
| | | | | | | | | | | | | | The recent commit adding the external toolchain wrapper has broken the support for external toolchain. The check_arm_eabi, check_cplusplus and check_cross_compiler_exists functions were using TARGET_CC, which points to the toolchain wrapper, but at the moment those functions are called, the wrapper hasn't been generated yet. We fix this by passing to these functions the path to the C or C++ compiler they should use for their tests. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: add a USE_MMU build optionGravatar Mike Frysinger2011-01-151-0/+2
| | | | | | | | | | Some packages need to know whether the MMU is in play, so add a toolchain option to expose the feature to them. [Peter: only show option on archs where it makes sense] Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: fix multilib symlink for external toolchainsGravatar Thomas Petazzoni2010-12-211-1/+1
| | | | | | | | | | ARCH_SUBDIR is a shell variable, so it should be referenced with $${ARCH_SUBDIR}. Without this, no symbolic link is created, and the external toolchain fails to work if the non-default multilib variant is used. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: check that the thread option selection is correctGravatar Thomas Petazzoni2010-12-131-1/+2
| | | | | | | | | | | When an external toolchain is used, the user is responsible for telling Buildroot what the configuration of the toolchain is. In order to make sure that the selection is correct, we already perform checks against the configuration of the uClibc in the selected external toolchain. This commit adds the check for thread support. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: rework C++ optionsGravatar Thomas Petazzoni2010-12-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Instead of having BR2_GCC_CROSS_CXX and BR2_INSTALL_LIBSTDCPP, with BR2_GCC_CROSS_CXX not being visible (and therefore being useless), let's just keep BR2_INSTALL_LIBSTDCPP to enable C++ in the toolchain and install C++ libraries on the target. We also take that opportunity to make BR2_INSTALL_LIBSTDCPP an hidden option, which is selected by an option in Buildroot toolchain support or an option in External toolchain support, just as we did for other toolchain features. Some work definitely remains to be done : - The name BR2_INSTALL_LIBSTDCPP is ugly, but we keep it for the moment in order to avoid changing all packages. - We should clarify the other language-related options (Fortran, Java, Objective-C, etc.). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: remove toolchain-specific strippingGravatar Thomas Petazzoni2010-12-131-9/+0
| | | | | | | | | | We already handle the stripping of libraries in $(TARGET_DIR) at the global level, so there's no need to have toolchain-specific option and code for this. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>