summaryrefslogtreecommitdiffstats
path: root/toolchain/external-toolchain
Commit message (Collapse)AuthorAgeFilesLines
* toolchain: rename external toolchain dirYann E. MORIN2010-07-283-154/+0
| | | | | | | | | Rename the external toolchain directory. When new backends are here, it will be easier to sort them out if they are all prefixed the same way. 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-241/+0
| | | | | | | | | 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>
* Create <tuple>/lib -> <sysroot>/lib symlink before installing cross gccThomas Petazzoni2010-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit solves bug #1051. The problem in this bug in that WebKit compiles a sample C program, which uses WebKit. As WebKit is written in C++, even though the program it built with CROSS-gcc, it must be linked with libstdc++. However, CROSS-gcc can't find the libstdc++ has it's hidden inside <sysroot>/<tuple>/lib. Therefore, this commit creates a symbolic link <sysroot>/<tuple>/lib -> <sysroot>/lib before running the CROSS-gcc installation. While this may look like a hack, this is the solution used by both Crosstool-NG and OpenWRT. Moreover, with this symbolic link in place, I think bug #1741 may also be solved. The problem in this bug is that the linker tries to link against /lib/libc.so.0. This is due to the fact that the linker finds a libc.so script file in the original toolchain location and not inside the copy of the toolchain sysroot in $(STAGING_DIR). As the script file is found outside of the current toolchain sysroot, ld considers the script has non-sysrooted, and therefore doesn't prefix all paths found in the script file (such as /lib/libc.so.0) with the sysroot path, leading to the failure. So, in details, this commit : * Adds a BR2_ARCH_IS_64 invisible config knob that is used to know if the arch is a 64 bits architecture or not. * Creates the <sysroot>/<tuple>/lib -> <sysroot>/lib symbolic link, and the <sysroot>/<tuple>/lib64 -> <sysroot>/lib64 symbolic link if needed. * Fixes the external toolchain sysroot detection code so that the 'sed' replacement is done *after* the readlink -f evaluation. I have tested this by building ARM, x86 and x86_64 toolchains with Buildroot, and then use these toolchains as external toolchains to build a full X.org/Gtk/WebKit/Midori stack. I have also done a complete ARM Buildroot internal toolchain build with the same full X.org/Gtk/WebKit/Midori stack. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* ext-toolchains: fix libnss_*.so installation with external glibcLuca Ceresoli2010-07-081-1/+1
| | | | | | | | Commit 7192668 introduced a wrong spelling of BR2_TOOLCHAIN_EXTERNAL_GLIBC that prevented libnss_files.so and libnss_dns.so from being installed. Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* external-toolchain: adjust tests on TARGET_CC and TARGET_CXXThomas Petazzoni2010-07-071-7/+9
| | | | | | | | | | | | | | Following the changes to TARGET_CC/TARGET_CXX to include the --sysroot option, these variables not only contain the path to the compiler, but also the --sysroot option. For that reason, we cannot anymore just use "test -x" to test for the compiler presence. Instead, we see if $(TARGET_CC) -v and $(TARGET_CXX) -v return a zero status. Moreover, --sysroot now needs to be filtered out of $(TARGET_CC) and not $(TARGET_CFLAGS) when asking the toolchain for its original sysroot and arch sysroot. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external-toolchain: hardcode the destination directory for a libraryThomas Petazzoni2010-07-061-13/+17
| | | | | | | | | | | | | | | | | | | | | | | Until now, the function copy_toolchain_lib_root was copying a given library to the target filesystem by assuming that it should be at the same place it was in the toolchain sysroot. However, with Buildroot hiding libstdc++ in /usr/<target-name>/lib(64), this isn't correct, and it is probably safer not to rely on the toolchain organization anyway. Therefore : * Instead of having a single EXTERNAL_LIBS variable, we now have LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS, which respectively list the libraries that should be copied to /lib and /usr/lib. As of today, only libstdc++ is part of the second list. * The copy_toolchain_lib_root takes another argument, which is the destination directory of the library, relative to $(TARGET_DIR) Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* external-toolchain: handle libstdc++/libgcc_s for BR toolchainsThomas Petazzoni2010-07-061-1/+10
| | | | | | | | | | Most toolchains have their libraries either in /lib or /usr/lib relative to their ARCH_SYSROOT_DIR. Buildroot toolchains, however, have basic libraries in /lib, and libstdc++/libgcc_s in /usr/<target-name>/lib(64). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* external-toolchain: recognize uClibc 64 bits toolchainsThomas Petazzoni2010-07-061-1/+1
| | | | | | | | | | With uClibc 64 bits toolchain, the dynamic loader is named ld64-uClibc.so.0 and not ld-uClibc.so.0. So, this commit adjust the uClibc detection code for external toolchains. 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>
* external-toolchain: mention MIPS and PowerPC CodeSourcery toolchainsThomas Petazzoni2010-07-061-1/+3
| | | | | Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* external-toolchain: create lib64 symlinks if neededThomas Petazzoni2010-07-061-0/+17
| | | | | | | | | | | | Create lib64 -> lib and usr/lib64 -> usr/lib symbolic links in the target and staging directories. This is needed for some 64 bits toolchains such as the Crosstool-NG toolchains, for which the path to the dynamic loader and other libraries is /lib64, but the libraries are stored in /lib. 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>
* external-toolchain: support 64 bits glibc toolchainsThomas Petazzoni2010-07-061-1/+1
| | | | | | | | | | On 64 bits glibc toolchains, the dynamic loader is named ld-linux-x86-64.so and not simply ld-linux.so. So, adjust the detection of the C library 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>
* external-toolchain: only copy existing directories of the sysrootThomas Petazzoni2010-07-061-1/+3
| | | | | | | | | | Instead of copying all directories in "etc lib sbin usr", check that each of them exists before doing the copy. This is only to avoid an harmless error message. 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>
* ext-toolchain: Fix ARCH_SYSROOT detectionThomas Petazzoni2010-07-061-9/+9
| | | | | | | | | | | | | | | | | | | | | | For the detection of the ARCH_SYSROOT_DIR (which contains the C library variant specific to the compiler flags), we used to pass only the -march argument instead of the full TARGET_CFLAGS. This was done because TARGET_CFLAGS contains --sysroot, and we don't want to tell here the compiler which sysroot to use, because we're specifically asking the compiler where the *normal* arch sysroot directory is. Unfortunately, there are some multilib variants that aren't decided only based on -march, but also on -msoft-float or other compiler flags. Therefore, we take the opposite approach: pass the full TARGET_CFLAGS, from which we have stripped the --sysroot option. For example, this allows a PowerPC CodeSourcery toolchain, on which we're using the soft-float multilib variant, to work properly as an external toolchain. 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>
* ext-toolchains: take into account other Glibc dynamic loader variantsThomas Petazzoni2010-07-061-6/+4
| | | | | | | | | | | | External toolchains using Glibc have different names for the dynamic loader. Some of them name it ld-linux.so.*, while some others (such as the PowerPC and MIPS CodeSourcery toolchains) name it simply ld.so.*. Therefore, we fix the glibc detection code to handle this case. 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>
* external toolchain: also copy the libthread_db.so for gdbserverYann E. MORIN2010-05-281-0/+3
| | | | | | | | | | gdbserver dlopen(3)s libthread_db.so at runtime, so there is no dependency on it (does not appear as being (NEEDED)). Copy libthread_db.so from external toolchain when gdbserver is enbled. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* toolchain/external: only copy the pthread lib if neededYann E. MORIN2010-05-281-1/+5
| | | | | | | | | | If threads are disabled, do not try to copy the libpthread.so from the external library. It is still expected that the BR configuration matches the external toolchain setup, and no check is done to enforce that. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* external toolchain: check BR2_INSTALL_LIBSTDCPPThomas Petazzoni2010-05-201-0/+12
| | | | | | | | Verify that the value of BR2_INSTALL_LIBSTDCPP set by the user in the Buildroot configuration really matches the external toolchain capabilities by checking that a C++ cross-compiler is available. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external-toolchain: Support for multilib toolchainsThomas Petazzoni2010-04-171-11/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Multilib toolchains provide different versions of the base libraries for different architecture variants. For example, the ARM Codesourcery toolchain provides base libraries for ARMv5 (default), ARMv4t and Thumb2. Depending on the -march= argument passed to gcc, the sysroot used by the compiler is therefore different. This means that the sysroot location in CROSS-gcc -v cannot be used. Instead, we must use CROSS-gcc -print-sysroot when available and fall back to the old way if unavailable. Moreover, we cannot simply copy the full sysroot as we used to do, because the sysroot organization of multilib toolchain is more complicated. In Codesourcery toolchains, we have : / etc -- for ARMv5 lib -- for ARMv5 sbin -- for ARMv5 usr -- for ARMv5 (includes headers) armv4t etc -- for ARMv4t lib -- for ARMv4t sbin -- for ARMv4t usr -- for ARMv4t (no headers!) thumb2 etc -- for Thumb2 lib -- for Thumb2 sbin -- for Thumb2 usr -- for Thumb2 (no headers!) So we have the default ARMv5 architecture variant that is installed in the main directory, and we have subdirectories for the ARMv4t and Thumb2 architecture variants. Copying the full sysroot to the staging directory doesn't work. All our packages are based on the fact that they should install libraries in staging/usr/lib. But if ARMv4t is used, the compiler would only look in staging/armv4t/usr/lib for libraries (even when overriding the sysroot with the --sysroot option, the multilib compiler suffixes the sysroot directory with the architecture variant if it matches a recognized one). Therefore, we have to copy only the sysroot that we are interested in. This is rendered a little bit complicated by the fact that the armv4t and thumb2 sysroot do not contain the headers since they are shared with the armv5 sysroot. So, this patch : * Modifies how we compute SYSROOT_DIR in order to use -print-sysroot if it exists. SYSROOT_DIR contains the location of the main sysroot directory, i.e the sysroot for the default architecture variant. * Defines ARCH_SUBDIR as the subdirectory in the main sysroot for the currently selected architecture variant (in our case, it can be ".", "armv4t" or "thumb2"). ARCH_SYSROOT_DIR is defined as the full path to the sysroot of the currently selected architecture variant. * Modifies copy_toolchain_lib_root (which copies a library to the target/ directory) so that libraries are taken from ARCH_SYSROOT_DIR instead of SYSROOT_DIR. This ensures that libraries for the correct architecture variant are properly copied to the target. * Modifies copy_toolchain_sysroot (which copies the sysroot to the staging/ directory), so that it copies the contents of ARCH_SYSROOT_DIR, and if needed, adds the headers from the main sysroot directory and a symbolic link (armv4t -> . or thumb2 -> .) to make the compiler believe that its sysroot is really in armv4t/ or thumb2/. Tested with Codesourcery 2009q1 ARM toolchain, Crosstool-NG ARM glibc and ARM uClibc toolchains. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external-toolchain: support libraries outside of /libThomas Petazzoni2010-04-171-10/+13
| | | | | | | | | | | | | The copy_toolchain_lib_root function was making the assumption that all libraries were stored inside the /lib directory of the sysroot directory. However, this isn't true for certain toolchains, particularly for the libstdc++ library. The function is therefore reworked to find the library and its related symlink either in /lib or /usr/lib in the sysroot, and copies it at the same location in the target directory. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: fix using external toolchains built with buildrootYann E. MORIN2010-04-071-8/+1
| | | | | | | | | | | | | | | | | | | The toolchains built with buildroot use specially crafted paths for their sysroot and prefix. Fix that by asking gcc where it finds a file we know by relative path to the sysroot. This has the side effect of greatly simplifying the sysroot detection in every cases tested so far (BR toolchains, CT-NG toolchains, and CodeSourcery toolchains). Fixes bug #851. Thanks Thomas Petazzoni for the hint and some testings. Thanks Grant Edwards for the report and the comments. Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* external toolchain: fix sysroot location if the toolchain was movedYann E. MORIN2010-03-311-1/+8
| | | | | | | | | Sysrooted toolchain can be relocated. In this case, the sysroot is no longer located at the place it was configured at. Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr> Acked-By: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* DNS resolv problem with glibcAnders Darander2009-09-151-1/+1
| | | | | | | | | | Fix problem with dns resolv, by copying the libnss_dns.so to the rootfs. Using glibc from external toolchain, name resolving does not work, unless libnss_dns.so is available on the target. Signed-off-by: Anders Darander <ad@datarespons.se> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Fix PROGRAM_INVOCATION handling with external toolchainsThomas Petazzoni2009-07-311-1/+3
| | | | | | | | | | | | | BR2_UCLIBC_PROGRAM_INVOCATION is a toolchain configuration option, like BR2_INET_IPV6, BR2_INET_RPC, on which some packages depend. Therefore, it should be handled like BR2_INET_IPV6 and BR2_INET_RPC in order to work properly with external toolchains. Since we move it out of toolchain/uClibc/Config.in into toolchain/Config.in.2, we rename the option to BR2_PROGRAM_INVOCATION (since BR2_INET_RPC and others don't have UCLIBC in their name). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external toolchain: check cross-compiler existenceThomas Petazzoni2009-07-171-0/+10
| | | | | | | | | As a minimal test to the external toolchain, check that $(TARGET_CC) is actually an existing executable file. That way, if the user misconfigures the toolchain path and/or prefix, a meaningful error message will be shown. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external toolchain: respect $(Q)Thomas Petazzoni2009-07-171-5/+5
| | | | | | | | Use $(Q) in external toolchain support so that the user can get the full output by passing V=1 to make, and still get a nice and clean output by default. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external toolchain: copy the C++ standard library if neededThomas Petazzoni2009-07-171-0/+4
| | | | | | | | Obey the BR2_INSTALL_LIBSTDCPP configuration option to copy the C++ standard library to the target. Suggested by Lionel Landwerlin <lionel.landwerlin@openwide.fr>. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external toolchain: do not copy useless symbolic linksThomas Petazzoni2009-07-171-1/+1
| | | | | | | Do not copy .so symbolic links to target when not needed. Only copy .so.X symbolic links and the library itself. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external toolchain: more documentation about the principlesThomas Petazzoni2009-07-171-0/+31
| | | | Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external toolchain: use LANG=C when calling gcc -vThomas Petazzoni2009-07-171-2/+2
| | | | | | | | | | | | Lionel Landwerlin <lionel.landwerlin@openwide.fr> reported that using the external toolchain support when LANG=fr_FR.UTF-8 doesn't work, since the messages printed by gcc -v are translated in another language, defeating the grep ^Configured test. Therefore, as per Lionel suggestion, we force LANG=C when calling $(TARGET_CC) -v. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external-toolchain: better documentation, cleanup, sysroot checkThomas Petazzoni2009-07-171-34/+81
| | | | | | | | | | | | | | | | * Introduce documentation for each function of ext-tool.mk, and document all parameters of the functions. * Pass SYSROOT_DIR as argument to all functions that require it, instead of computing it manually everywhere * Use $(shell) instead of backquotes * Check that the SYSROOT_DIR variable is not empty, which means that the external toolchain doesn't support --sysroot. In that case, bail out with a nice error message. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* external toolchain: fix libraries copy and add ARM ABI checkThomas Petazzoni2009-07-161-20/+37
| | | | | | | | | | Instead of hardcoding the C library versions, just copy the version available in $SYSROOT_DIR/lib. Add a check on the ARM ABI configured in Buildroot with regard to the ABI of the external toolchain provided. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Improve external toolchain checksThomas Petazzoni2009-06-151-0/+51
| | | | | | | | | | | | | | | | | | | | | This patch adds some checks on the external toolchains. First, it checks that the C library selection is correct, by looking if gcc is able to find the main C library file through the -print-file-name option. Then, it attempts to check if the Buildroot toolchain options match the configuration of the toolchain : * for glibc, it checks that IPv6, RPC, locales, wide-char, large file support Buildroot options are enabled, since with glibc all these features are always available (at least this is the assumption we make) ; * for uClibc, it checks the Buildroot options with the uClibc configuration file in $SYSROOT_DIR/usr/include/bits/uClibc_config.h Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Simple glibc-based external toolchain supportThomas Petazzoni2009-06-152-23/+26
| | | | | | | | | | | | | | | | | | | | The current Buildroot works just well with sysrootable glibc toolchains, using the external toolchain feature. The only thing that needs to be customized is the set of libraries that must be compiled to the target. The following patch takes a simple approach to making it easier for users to use glibc toolchains. It just adds a uClibc/glibc choice in the external toolchain menu. Then, depending on that selection, the configuration system will choose a sane default value for the library files list. The other advantage of having a uClibc/glibc choice is that in the future, we'll be able to add checks verifying that the external toolchain configuration matches the features selected in Buildroot (in terms of IPv6, RPC, locales or large file support). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* 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
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-04 00:33:48 +0000