buildroot.git/toolchain/external-toolchain, branch 2011.08_rc2

toolchain: rename external toolchain dir

2010-07-28T14:20:03Z

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 Signed-off-by: Peter Korsgaard

toolchain: move helper functions from external toolchain

2010-07-28T14:19:56Z

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 Signed-off-by: Peter Korsgaard

Create /lib -> /lib symlink before installing cross gcc

2010-07-27T20:49:36Z

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 //lib. Therefore, this commit creates a symbolic link //lib -> /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 //lib -> /lib symbolic link, and the //lib64 -> /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

ext-toolchains: fix libnss_*.so installation with external glibc

2010-07-08T21:06:53Z

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 Signed-off-by: Peter Korsgaard

external-toolchain: adjust tests on TARGET_CC and TARGET_CXX

2010-07-07T06:18:42Z

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

external-toolchain: hardcode the destination directory for a library

2010-07-06T06:01:00Z

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//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 Signed-off-by: Peter Korsgaard

external-toolchain: handle libstdc++/libgcc_s for BR toolchains

2010-07-06T06:00:22Z

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//lib(64). Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

external-toolchain: recognize uClibc 64 bits toolchains

2010-07-06T05:59:39Z

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 Reviewed-by: Yann E. MORIN Signed-off-by: Peter Korsgaard

external-toolchain: mention MIPS and PowerPC CodeSourcery toolchains

2010-07-06T05:59:19Z

Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

external-toolchain: create lib64 symlinks if needed

2010-07-06T05:58:46Z

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 Reviewed-by: Yann E. MORIN Signed-off-by: Peter Korsgaard