aboutsummaryrefslogtreecommitdiffstats
path: root/toolchain/helpers.mk
Commit message (Collapse)AuthorAgeFilesLines
* toolchain-external: improve glibc support to test availability of RPCThomas 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_RPCThomas 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-linuxJean-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 typoPeter 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.05Thomas 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 toolchainsThomas 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.01Thomas 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 toolchainsThomas 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-subdirectoriesThomas 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 toolchainThomas 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_BUILDROOTPeter 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 issuesGustavo 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 copyingMike 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 sysrootThomas 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 removalPeter 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 optionPeter 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 supportThomas 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 optionMike 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 toolchainsThomas 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 correctThomas 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++ optionsThomas 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 strippingThomas 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>
* toolchain: remove ending semi-colon in helpersThomas Petazzoni2010-12-131-4/+4
| | | | | | | | | | | Some helpers had their final line ending with a semi-colon, some did not. For consistency, remove the final semi-colon from all helpers, it's the responsability of the caller to add the final semi-colon as needed. 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: fix helpers for POSIX complianceYann E. MORIN2010-09-301-4/+4
| | | | | | | | Using two '=' for string comparison is a bashism. Revert to using one, as stated in POSIX 1003.1-2008. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: move helper functions from external toolchainYann E. MORIN2010-07-281-0/+244
The helper functions used for external toolchains may also be useful to alternate toolchain backends (currently, the external toolchain is the sole user). Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>