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>
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>
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>
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>
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>
* 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>
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>
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>
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>
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.
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>
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).
* 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 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>
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>
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>
