buildroot-novena/toolchain/external-toolchain, branch 2010.05_rc2

external-toolchain: Support for multilib toolchains

2010-04-17T00:09:38+00:00

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

external-toolchain: support libraries outside of /lib

2010-04-17T00:09:38+00:00

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

toolchain: fix using external toolchains built with buildroot

2010-04-07T07:49:20+00:00

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

external toolchain: fix sysroot location if the toolchain was moved

2010-03-31T08:50:40+00:00

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 Acked-By: Thomas Petazzoni Signed-off-by: Peter Korsgaard

DNS resolv problem with glibc

2009-09-15T06:50:12+00:00

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

Fix PROGRAM_INVOCATION handling with external toolchains

2009-07-31T09:40:34+00:00

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

external toolchain: check cross-compiler existence

2009-07-17T06:53:55+00:00

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

external toolchain: respect $(Q)

2009-07-17T06:48:35+00:00

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

external toolchain: copy the C++ standard library if needed

2009-07-17T06:46:51+00:00

Obey the BR2_INSTALL_LIBSTDCPP configuration option to copy the C++ standard library to the target. Suggested by Lionel Landwerlin . Signed-off-by: Thomas Petazzoni

external toolchain: do not copy useless symbolic links

2009-07-17T06:46:43+00:00

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