Commit Graph

20 Commits

Author SHA1 Message Date
Thomas Petazzoni
e1f0804cc1 external-toolchain: add support for recent Linaro toolchains
Starting from 2012.03, the Linaro toolchains have separated the GCC
support libraries (libstdc++, libgcc_s) from the sysroot itself. So we
no longer have the case where all libraries are inside the sysroot, as
we had for all the previously supported toolchains.

Therefore, we add some logic to detect if such a separate directory is
used for GCC support libraries, and if it's the case, we make sure
that we take into account this directory when creating our own
sysroot, and when copying libraries to the target filesystem.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-05-07 17:08:37 +02:00
Thomas Petazzoni
e6e60becb0 external-toolchain: add support for Linaro 2012.01
Linaro has just released a new pre-built toolchain, available as a
tarball, which is a pure toolchain (only the C library is
included). This makes this new Linaro 2012.01 toolchain usable in
Buildroot, so let's integrate the support for it.

In addition to simply adding the new external toolchain at the usual
locations, this patch allows need to adapt a few things to support
Linaro toolchains. Most toolchains store their libraries in the "lib/"
or "usr/lib" directories relative to the toolchain. Buildroot
toolchains on the other hand, store the libraries in the
"usr/<target-name>/lib" directory. And the Linaro toolchain has
choosen to use the "lib/<target-name>" directory. Therefore, this
patch adjust:

 * The logic to search a particular library when that library needs to
   be copied to the target directory

 * The logic to deduce the sysroot directory from the libc.a file
   location in the toolchain: removing "(usr/?)lib(64?)" is no longer
   sufficient, we need to take into account the "lib/<target-name>/"
   case.

Since the Linaro toolchain generates code for Cortex-A processors
only, the selection of this toolchain is limited to Cortex-A8 and
Cortex-A9.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-03-01 20:26:38 +01:00
Thomas Petazzoni
090d486441 external-toolchain: adjust check for uClibc static toolchains
The current check for uClibc toolchain was verifying that a
ld-uClibc.so dynamic loader was present. However, with static-only
uClibc toolchains, this does not work. Instead, we check for an
uClibc-specific header file in the sysroot.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-03-01 20:26:38 +01:00
Thomas Petazzoni
50ac5f9a57 Support multilib variants in sub-subdirectories
When an external toolchain has multiple variants organized in
sub-directories, Buildroot only copies the selected sysroot and not
all sysroots. In order to make this work, Buildroot creates a symbolic
link of the name of the original selected sysroot to the main sysroot
to trick the compiler so that it finds its libraries at the expected
location.

I.e, if the toolchain as the following organization (example take on
the ARM CodeSourcery toolchain) :

     .	    	for ARMv5T
     armv4  	for ARMv4T
     thumb2 	for ARMv7-A/Thumb

and ARMv4T is selected, then Buildroot will copy the contents of
armv4t/ from the toolchain into its $(STAGING_DIR) and then create a
$(STAGING_DIR)/armv4t symbolic link to $(STAGING_DIR).

However, our logic to do so only works when there was one directory
level for multilib sysroots. But in the MIPS CodeSourcery toolchain
there are multiple levels. For example, the MIPS16 soft-float
little-endian sysroot variant is in mips16/soft-float/el/ compared to
the main sysroot.

This patch improves our logic to support this case. The logic is a bit
more complicated as we don't want to create a symbolic link to an
absolute path, but a symbolic link to a relative path, because we want
the host/ directory to be relocatable.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-03-01 20:26:36 +01:00
Thomas Petazzoni
0729b544b3 Improve external toolchain logic to support IA32 Sourcery CodeBench toolchain
The IA32 Sourcery CodeBench toolchain has a relatively special
structure, with the following multilib variants:

 * Intel Pentium 4, 32 bits, the multilib variant is in ./ relative to
   the main sysroot, with the libraries in the lib/ directory.

 * Intel Xeon Nocona, 64 bits, the multilib variant is in ./ relative
   to the main sysroot, with the libraries in the lib64/ directory.

 * Intel Atom 32 bits, the multilib variant is in atom/ relative to
   the main sysroot, with the libraries in the lib/ directory.

 * Intel Core 2 64 bits, the multilib variant is in core2/ relative to
   the main sysroot, with the libraries in lib64/ directory.

So the first two variants are in the same sysroot, only the name of
the directory for the libraries is different.

Therefore, we introduce a new ARCH_LIB_DIR variable, which contains
either 'lib' or 'lib64'. This variable is defined according to the
location of the libc.a file for the selected multilib variant, and is
then used when copying the libraries to the target and to the staging
directory.

In addition to this, we no longer use the -print-multi-directory to
get the ARCH_SUBDIR, since in the case of the 64 bits variants of this
toolchain, it returns just '64' and not a real path. Instead, we
simply compute the difference between the arch-specific sysroot and
the main sysroot.

We also take that opportunity to expand the documentation on the
meaning of the different variables.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2012-03-01 20:26:36 +01:00
Peter Korsgaard
5931db0de9 gdb: fix kconfig dependency handling with !BR_TOOLCHAIN_BUILDROOT
Newer versions of GDB need pthread debugging support if threads are
enabled, which is always the case for glibc but is a configure option
for uClibc.

We have solved this for internal toolchains by selecting the
BR2_PTHREAD_DEBUG option from the GDB selection if needed, but as this
option isn't available when ctng/external toolchains are used, mconf
prints ugly warnings and the build may fail if an external uClibc
toolchain without pthread debugging support is used.

Fix it by introducing 2 more hidden config options:
 - BR2_TOOLCHAIN_HAS_THREADS_DEBUG
 - BR2_TOOLCHAIN_HAS_THREADS_DEBUG_IF_NEEDED

The first tells us if the toolchain HAS pthreads debugging support,
and is checked by check_uclibc_feature in helper.mk for external uClibc
based toolchains.

The second tells us if the toolchain is ABLE TO provide pthreads debugging
support if threads are enabled, either because it's an internal toolchain
where we can force enable it or an external glibc/eglibc toolchain or
uClibc with the option enabled.

Crosstool-ng forcibly enables this support, so those will always work.
The preconfigured uClibc-based toolchains we have also all enable it.

Finally, show a comment if this isn't the case so the (external toolchain)
user knows why. This is placed outside the choice option, as menuconfig
has a bug where it doesn't show choice selections which only contain
comments.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-11-24 14:26:52 +01:00
Gustavo Zacarias
d453d0bc9c ext-toolchain: fix ct-ng as external rsync issues
When using a CT-NG toolchain as external toolchain (not with the
integration) and said toolchain has u-w directories rsync fails.
So instruct rsync to chmod u+w directories in the target copy to avoid
the issue.

[Peter: notice that this is a workaround for a rsync 3.0.8 bug]
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-11-02 12:28:41 +01:00
Mike Frysinger
da6353c9e7 toolchain: speed up sysroot lib copying
The copy_toolchain_lib_root helper searches the entire sysroot, but is
only interested in files in certain subdirs.  So rather than waste time
in walking the entire tree, walk the few subdirs at the depth level we
are actually going to be poaching files from.

Some simplification suggested by Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> and Arnout Vandecappelle
<arnout@mind.be>, added by Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-10-10 09:47:23 +02:00
Thomas Petazzoni
2c23e93766 external toolchain: slightly optimize the copy of the toolchain sysroot
The sysroot of an ARM CodeSourcery toolchain takes about 1.4 GB of
space, but 1.1+ GB of this space consists in locale-related
information which Buildroot doesn't use. By skipping the copy of those
unused files, we save quite a bit of time while importing the
toolchain sysroot.

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>
2011-10-09 21:24:58 +02:00
Peter Korsgaard
70db1984dc toolchain/helpers.mk: unbreak check_glibc after PROGRAM_INVOCATION removal
As noticed by Thomas Petazzoni on IRC.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-07-29 09:09:44 +02:00
Peter Korsgaard
4ee9d569f9 uClibc: drop BR2_PROGRAM_INVOCATION option
Remove the BR option and enable the configuration setting in the
uClibc defconfigs.

The BR2_PROGRAM_INVOCATION option only adds very little overhead to
uClibc, and we have a number of packages needing it, so simply always
enable it - Simplifying the kconfig logic and the number of choices
users have to make.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-07-27 11:56:53 +02:00
Thomas Petazzoni
c59d024754 external-toolchain: fix support
The recent commit adding the external toolchain wrapper has broken the
support for external toolchain. The check_arm_eabi, check_cplusplus
and check_cross_compiler_exists functions were using TARGET_CC, which
points to the toolchain wrapper, but at the moment those functions are
called, the wrapper hasn't been generated yet.

We fix this by passing to these functions the path to the C or C++
compiler they should use for their tests.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-05-08 21:56:10 +02:00
Mike Frysinger
e5e5f5d868 toolchain: add a USE_MMU build option
Some packages need to know whether the MMU is in play, so add a toolchain
option to expose the feature to them.

[Peter: only show option on archs where it makes sense]
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-01-15 14:23:36 +01:00
Thomas Petazzoni
cd11bf4970 toolchain: fix multilib symlink for external toolchains
ARCH_SUBDIR is a shell variable, so it should be referenced with
$${ARCH_SUBDIR}. Without this, no symbolic link is created, and the
external toolchain fails to work if the non-default multilib variant
is used.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-21 13:57:11 +01:00
Thomas Petazzoni
42e32d55b1 toolchain: check that the thread option selection is correct
When an external toolchain is used, the user is responsible for
telling Buildroot what the configuration of the toolchain is. In order
to make sure that the selection is correct, we already perform checks
against the configuration of the uClibc in the selected external
toolchain. This commit adds the check for thread support.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-13 22:26:51 +01:00
Thomas Petazzoni
6b578c8d73 toolchain: rework C++ options
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>
2010-12-13 22:04:35 +01:00
Thomas Petazzoni
01b434b27a toolchain: remove toolchain-specific stripping
We already handle the stripping of libraries in $(TARGET_DIR) at the
global level, so there's no need to have toolchain-specific option and
code for this.

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>
2010-12-13 22:02:32 +01:00
Thomas Petazzoni
ac38fd3dc6 toolchain: remove ending semi-colon in helpers
Some helpers had their final line ending with a semi-colon, some did
not. For consistency, remove the final semi-colon from all helpers,
it's the responsability of the caller to add the final semi-colon as
needed.

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>
2010-12-13 21:55:48 +01:00
Yann E. MORIN
d12bc6294a toolchain: fix helpers for POSIX compliance
Using two '=' for string comparison is a bashism.
Revert to using one, as stated in POSIX 1003.1-2008.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-09-30 22:08:54 +02:00
Yann E. MORIN
ed181aeedb toolchain: move helper functions from external toolchain
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>
2010-07-28 16:19:56 +02:00