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>
x86-64 stores libgcc_s / libstdc++ / libgcj under lib64 instead of lib,
so make sure that directory is searched as well for libraries to copy
to target.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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>
Add BR2_ENABLE_LOCALE_PURGE / BR2_ENABLE_LOCALE_WHITELIST options to
remove unwanted locales from the target rootfs. Handy for stuff like
the gtk stack, which comes with ~25 MB locales.
Works similar to localepurge in Debian, E.G. you provide a white list
of wanted locales, and everything else is removed.
We add the wchar stuff at compile time using sed, so the default defconfig
works, the file hasn't seen any updates since it first got committed, and
there's no references to it in the tree.
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.
"target/device/Atmel/arch-avre/kernel-headers-2.6.28.2"
Make sure BR2_KERNEL_HEADERS_PATCH_DIR is enabled for 2.6.28
Set
KERNEL_HEADERS_PATCH_DIR="target/device/Atmel/arch-avre/kernel-headers-2.6.28.2"
for Atmel AVR32 targets and "valka"
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>
The GNU_TARGET_NAME symlink and target_utils location were not correctly
adjusted to match the move of the toolchain to $(STAGING_DIR)/usr,
creating dangling symlinks.
This variable was introduced in r17046 (add gfortran support,
2006-12-22) and wasn't used even there.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
The buildroot toolchain is installed in $(STAGING_DIR)/usr/bin and not
in $(STAGING_DIR)/bin so let,s adjust the --prefix accordingly.
Also the BFLT binary format is always stripped by definition, so it is
incompatible with any kind of stripping option.
Signed-off-by: Nicolas Pitre <nico@cam.org>
UCLIBC_SUPPORT_AI_ADDRCONFIG seems to have issues in 0.9.30 and cause
segfaults on some architectures, so disable it.
Reported and tracked down by "QuickX" <quickx@hotmail.com>.
gcc < 4.2.0 doesn't support -Wno-overlength-stings, but gcc-4.3.x configure
fails to detect that, breaking the build.
Work around it by detecting the host gcc version (and store in HOSTCC_VERSION)
and set the proper configure variables for gcc < 4.2.0.
The VFP is only available for a few ARM CPUs at the moment,
so this breaks the liboil build.
A patch is available upstream which only enables "-mfpu=vfp"
if "--enable-vfp" is given to "configure".
Autotools needs to be run for liboil for this to take effect.
A new configuration BR2_VFP_FLOAT is added to allow enabling vfp.
If this is "yes", then "-mfpu=vfp" is added to CFLAGS.
- arch/sh and arch/sh64 got merged in 2.6.25, so use arch/sh for sh64 as well
- use little endian for sh64, like for 32bit sh
sh64 still doesn't build, but gets further along now.
git-svn (and git) doesn't handle empty directories, so add .empty files
to those dirs like elsewhere in buildroot.
Those empty directories are normally not a big deal, but the recent changes
to u-boot broke the build.
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>
