Commit Graph

23 Commits

Author SHA1 Message Date
Anders Darander
b96253a63e DNS resolv problem with glibc
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 <ad@datarespons.se>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2009-09-15 08:50:12 +02:00
Thomas Petazzoni
8d880c3e5c Fix PROGRAM_INVOCATION handling with external toolchains
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 <thomas.petazzoni@free-electrons.com>
2009-07-31 11:40:34 +02:00
Thomas Petazzoni
901b468e24 external toolchain: check cross-compiler existence
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>
2009-07-17 08:53:55 +02:00
Thomas Petazzoni
82bf777ed7 external toolchain: respect $(Q)
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>
2009-07-17 08:48:35 +02:00
Thomas Petazzoni
28aa0b47fb external toolchain: copy the C++ standard library if needed
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>
2009-07-17 08:46:51 +02:00
Thomas Petazzoni
3026e9930e external toolchain: do not copy useless symbolic links
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>
2009-07-17 08:46:43 +02:00
Thomas Petazzoni
0afd2103f0 external toolchain: more documentation about the principles
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2009-07-17 00:20:33 +02:00
Thomas Petazzoni
fd5570970e external toolchain: use LANG=C when calling gcc -v
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>
2009-07-17 00:10:46 +02:00
Thomas Petazzoni
57692e2535 external-toolchain: better documentation, cleanup, sysroot check
* 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>
2009-07-17 00:10:33 +02:00
Thomas Petazzoni
00eddf0ee6 external toolchain: fix libraries copy and add ARM ABI check
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>
2009-07-16 21:45:00 +02:00
Thomas Petazzoni
9456b58a8b Improve external toolchain checks
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>
2009-06-15 20:48:27 +02:00
Thomas Petazzoni
643aa232f0 Simple glibc-based external toolchain support
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>
2009-06-15 20:48:27 +02:00
Peter Korsgaard
16a5a68947 toolchain: revert r25193 (Change binary toolchain configuration)
As discussed on the list.
2009-02-04 13:42:40 +00:00
Ulf Samuelsson
59f084017e Change binary toolchain configuration, so
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.
2009-01-31 20:49:59 +00:00
Daniel Laird
215e91f132 toolchain/external-toolchain/ext-tool.mk: Support non sysroot-able toolchains
Only copy the sysroot files if the toolchain was built with sysroot support.

Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
2009-01-12 12:54:30 +00:00
Thomas Petazzoni
978d8dc53e Another external toolchain support solution
* 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>
2008-12-13 16:15:50 +00:00
Peter Korsgaard
df1df36fcb More external toolchain fixes
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>
2008-11-03 10:32:59 +00:00
Peter Korsgaard
e241fa4290 Typo fix in toolchain/external-toolchain/ext-tool.mk
From: Grant Likely <grant.likely@secretlab.ca>

Comment block header documentation typo
2008-10-17 10:19:38 +00:00
Bernhard Reutner-Fischer
6547bced93 - global whitespace trimming 2007-08-22 12:35:41 +00:00
Bernhard Reutner-Fischer
3471ebe0a3 - random whitespace cleanup 2007-08-22 11:47:22 +00:00
Bernhard Reutner-Fischer
956d3eb78b - semicolon touchup. No other changes 2007-08-22 09:56:41 +00:00
"Steven J. Hill"
d3f3d1c7ad Some 'find' commands get a little picky. 2007-04-19 02:04:15 +00:00
"Steven J. Hill"
02f71aab47 Support building using an external toolchain. Questions to the mailing list and all other comments to <biteme@devnull.com>. 2007-02-06 18:19:38 +00:00