summaryrefslogtreecommitdiffstats
path: root/toolchain/external-toolchain
Commit message (Collapse)AuthorAgeFilesLines
* toolchain: revert r25193 (Change binary toolchain configuration)Peter Korsgaard2009-02-042-5/+1
| | | | As discussed on the list.
* Change binary toolchain configuration, soUlf Samuelsson2009-01-312-1/+5
| | | | | | | | | | | that the options become visible just below the config, instead of at bottom of screen Create a more useful default as toolchain path. Allow generation of a script which sets up paths to a binary toolchain generated by buildroot.
* Extend External Toolchain options (match buildroot built toolchain): Daniel Laird2009-01-301-60/+0
| | | | | | | | | | Have added options that mean you can set the same BR2_XXXX variables for external toolchain and internal (buildroot built) toolchain. This means the same set of packages can be built now me as for you..... Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
* toolchain/external-toolchain/ext-tool.mk: Support non sysroot-able toolchainsDaniel Laird2009-01-121-3/+3
| | | | | | | Only copy the sysroot files if the toolchain was built with sysroot support. Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
* toolchain: use same gdb Config.in for internal/external toolchainsPeter Korsgaard2008-12-152-81/+77
| | | | | | | | | | We used to use different gdb configs for internal and external toolchains because mconf won't source the same file twice. This works, but is kind of sub optimal, as people forget to keep them in sync. Fix it to use the same file for both situations by shuffling around the config options a bit. Should work identical to before (except for the newer gdb versions available for ext).
* Another external toolchain support solutionThomas Petazzoni2008-12-131-0/+6
| | | | | | | | | | | | | | | | | | | | * In toolchain/external-toolchain/ext-tool.mk, copy the contents of the sysroot directory to the staging dir. * In package/Makefile.in, add a --sysroot CFLAGS pointing to the staging dir * Remove the CFLAGS and LDFLAGS definition from TARGET_CONFIGURE_OPTS. I haven't investigated exactly why, but with these options, DirectFB fails to build because it cannot find PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP, even if DirectFB's Makefile properly sets -D_GNU_SOURCE. I have already sent this patch on December, 2nd to the mailing-list, but got no feedback. So let's commit and see what happens :-) Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* External toolchain C++ cross-compiler fixPeter Korsgaard2008-11-031-0/+6
| | | | | | | | | | | | | | | | External toolchain C++ cross-compiler fix package/Makefile.in resets CXX to "" in TARGET_CONFIGURE_OPTS if BR2_GCC_CROSS_CXX is not set to 'y'. However, when using an external toolchain, BR2_GCC_CROSS_CXX is not set even if the toolchain has a C++ cross-compiler. This patch adds a new BR2_GCC_CROSS_CXX option in the external toolchain configuration menu, so that just like BR2_INET_RPC, BR2_INET_IPV6 and the others, it can be set according to the external toolchain configuration. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* More external toolchain fixesPeter Korsgaard2008-11-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix issues with binary external toolchains Fix two problems encountered while using an external binary toolchain generated by crosstool-ng: - Don't remove the ending / in LIB_DIR, otherwise find $LIB_DIR -maxdepth 1 doesn't find any file in the case LIB_DIR is a symbolic link and not a directory. For some reason, find -maxdepth 1 doesn't have the same behaviour on directories and symbolic links. Demonstration: $ mkdir foobar $ touch foobar/t1 $ touch foobar/t2 $ ln -s foobar barfoo $ find foobar -maxdepth 1 -name 't*' foobar/t1 foobar/t2 $ find barfoo -maxdepth 1 -name 't*' $ find barfoo/ -maxdepth 1 -name 't*' barfoo/t1 barfoo/t2 * Make sure the libraries are writable, otherwise the strip operation might fail. The library files may not be writable if the toolchain is not writable (which may happen if one wants to prevent anyone from overwriting the toolchain, which is done by crosstool-ng, for example). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* External toolchain support improvementsPeter Korsgaard2008-11-031-13/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Improve external toolchain support * Do not put kernel-headers in the dependencies of BASE_TARGETS in the case where BR2_TOOLCHAIN_SOURCE is not y. The kernel headers are already supposed to be part of the external toolchain, so there's no need to download, extract and install them. * In the configuration system, don't display the kernel headers version selection list when an external toolchain is selected. This is implemented by moving the source "toolchain/kernel-headers/Config.in" inside the if BR2_TOOLCHAIN_SOURCE in toolchain/Config.in.2. * Change the description and help message of the BR2_LARGEFILE, BR2_INET_IPV6, BR2_INET_RPC, and BR2_SOFT_FLOAT option in toolchain/external-toolchain/Config.in. In the case of an external toolchain, the semantic of these options is not to enable large file support, IPV6 or RPC (since the toolchain is already compiled, it has been decided previously). Their semantic is to let Buildroot know about the characteristics of the external toolchain being used. As an improvement, we could guess these values automatically: - for BR2_LARGEFILE, look at the value of __UCLIBC_HAS_LFS__ in bits/uClibc_config.h in the libc headers directory. - for BR2_INET_RPC, look at the value of __UCLIBC_HAS_RPC__ in the same file - for BR2_INET_IPV6, look at the value of __UCLIBC_HAS_IPV6__ in the same file - for BR2_SOFT_FLOAT, look at the output of $(CC) -v 2>&1 | grep -- "--with-float=soft" But I'm not sure how this would be possible, since these values are used at configuration-time by other configuration options, not only at build time. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Typo fix in toolchain/external-toolchain/ext-tool.mkPeter Korsgaard2008-10-171-1/+1
| | | | | | From: Grant Likely <grant.likely@secretlab.ca> Comment block header documentation typo
* Kconfig: remove 'default n'Peter Korsgaard2008-07-171-3/+0
| | | | 'default n' is the default, so there's no need to say it explicitly.
* toolchain: more sensible uclibc defaults for external toolchainPeter Korsgaard2008-06-161-4/+4
|
* - revert some bad checkins, fixup bad settings in atmel targets and move the ↵Bernhard Reutner-Fischer2007-09-261-3/+4
| | | | gcc target abi back to a place where the other arch-specific settings live
* reinstate AVR32 toolchainUlf Samuelsson2007-09-261-4/+3
|
* - remove one invariant in toolchain type selection.Bernhard Reutner-Fischer2007-09-251-3/+4
|
* - Subsume and collaps toolchain options in one menuBernhard Reutner-Fischer2007-09-221-1/+1
| | | | | This is ment to ease configuration by providing toolchain related options in one place No functional changes, just shuffling the menus around..
* - global whitespace trimmingBernhard Reutner-Fischer2007-08-221-37/+37
|
* - random whitespace cleanupBernhard Reutner-Fischer2007-08-221-1/+1
|
* - semicolon touchup. No other changesBernhard Reutner-Fischer2007-08-221-4/+4
|
* Allow selection of RPC and IPv6 options for an external toolchain."Steven J. Hill"2007-07-171-0/+12
|
* When using an external toolchain, we still need to have the user select ↵"Steven J. Hill"2007-04-281-2/+25
| | | | which thread model the toolchain was built with. This allows for proper building of LTP and possibly other packages.
* Some 'find' commands get a little picky."Steven J. Hill"2007-04-191-1/+1
|
* Support building using an external toolchain. Questions to the mailing list ↵"Steven J. Hill"2007-02-062-0/+128
and all other comments to <biteme@devnull.com>.