summaryrefslogtreecommitdiffstats
path: root/toolchain/toolchain-buildroot/Config.in.2
Commit message (Collapse)AuthorAgeFilesLines
* toolchain: drop BR2_CROSS_TOOLCHAIN_TARGET_UTILS optionGustavo Zacarias2010-12-291-12/+0
| | | | | | | | | It's really not very useful, all it does is install a target strace and ldd in a target_utils directory in staging. While at it clean up the strace makefile a bit. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* sstrip: make it a proper packageGustavo Zacarias2010-12-281-1/+0
| | | | | | | | | | | * Convert sstrip to a proper gentargets package * Use openwrt svn version, it's basically the same one we used * Change the hooks from old toolchain/sstrip to new package/sstrip * Drop the old toolchain/sstrip directory * sstrip for the target is now in Package -> Development Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain/uClibc: add 0.9.32-rc1Peter Korsgaard2010-12-271-1/+1
| | | | Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: rework thread optionsThomas Petazzoni2010-12-131-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | The selection of linuxthreads, linuxthreads old or NPTL doesn't make a lot of sense for external toolchains. So, instead, we : * Introduce an hidden BR2_TOOLCHAIN_HAS_THREADS option, which must be selected by toolchain specific options when thread support is available. Package needing to test thread support should use this option. * Move the none/linuxthreads/linuxthreads old/NPTL selection to Buildroot internal toolchain configuration. * Add an option in external toolchain to tell if thread support is available or not in the external toolchain. We assume that glibc without threads is not possible, as Ulrich Drepper said in http://sourceware.org/ml/libc-alpha/2005-08/msg00091.html ffmpeg, dmalloc and openvpn are fixed to use the new BR2_TOOLCHAIN_HAS_THREADS option. For openvpn, --enable-threads=posix is no longer used, as the configure script doesn't even understand this option. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain: move Stack Protection Support optionThomas Petazzoni2010-12-131-0/+9
| | | | | | | | | | The BR2_USE_SSP option is only used inside the uClibc build, so only meaningful for Buildroot internal toolchains. Therefore, the option is moved to the right location so that it isn't visible when working with external toolchains. 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-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | 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: Improve C library option selectionThomas Petazzoni2010-12-131-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Turn BR2_LARGEFILE, BR2_INET_IPV6, BR2_INET_RPC, BR2_USE_WCHAR, BR2_ENABLE_LOCALE and BR2_PROGRAM_INVOCATION into hidden options. Then, for Buildroot toolchains, external toolchains and Crosstool-NG toolchains, provide visible options that selects the hidden options. This allows : * To show a different label and help text in the case of Buildroot toolchain (do you want to enable feature X ?) and in the case of external toolchain (is feature X available in your toolchain ?) * To not show any option when a glibc external toolchain is selected (since glibc is assumed to support all of largefile, IPv6, RPC, WCHAR, locale and program invocation) and have them all selected in that case. There is some amount of duplication between Buildroot toolchain config options and Crosstool-NG toolchain config options, because kconfig doesn't allow to source the same Config.in file twice (even if under mutually exclusive conditions). This duplication is more readable that the hack that consists in splitting files in multiple pieces. However, this commit changes the name of the options visible in the configuration interface, so existing .config files will have to be updated accordingly. 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 multilibThomas Petazzoni2010-07-281-5/+0
| | | | | | | | | | | | | Supporting multilib is much more than just passing --enable-multilib to gcc. You have to actually build the C library several times (once for each multilib variant you want to support in your toolchain), and to pass MULTILIB_OPTIONS/MULTILIB_EXCEPTIONS values to gcc to let it know the set of multilib variants you're interested in. Since we'll probably never support multilib toolchains in Buildroot, just get rid of this BR2_ENABLE_MULTILIB option. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: move buildroot config filesYann E. MORIN2010-07-281-0/+37
Handle the internal toolchain backend mechanism the same way we handle other backends. Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>