Now that TARGET_CC contains several space-separated words, it must be
used quoted everywhere.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Following the changes to TARGET_CC/TARGET_CXX to include the --sysroot
option, these variables not only contain the path to the compiler, but
also the --sysroot option. For that reason, we cannot anymore just use
"test -x" to test for the compiler presence. Instead, we see if
$(TARGET_CC) -v and $(TARGET_CXX) -v return a zero status.
Moreover, --sysroot now needs to be filtered out of $(TARGET_CC) and
not $(TARGET_CFLAGS) when asking the toolchain for its original
sysroot and arch sysroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The external toolchain and internal toolchain cases both need to use
the --sysroot option, and they have almost identical
LDFLAGS/CFLAGS/CXXFLAGS definition, so we can factorize these
definitions.
Moreover, the --isysroot option is implied by --sysroot so there's no
need to specify both.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Until now, the function copy_toolchain_lib_root was copying a given
library to the target filesystem by assuming that it should be at the
same place it was in the toolchain sysroot.
However, with Buildroot hiding libstdc++ in
/usr/<target-name>/lib(64), this isn't correct, and it is probably
safer not to rely on the toolchain organization anyway.
Therefore :
* Instead of having a single EXTERNAL_LIBS variable, we now have
LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS, which respectively
list the libraries that should be copied to /lib and /usr/lib. As
of today, only libstdc++ is part of the second list.
* The copy_toolchain_lib_root takes another argument, which is the
destination directory of the library, relative to $(TARGET_DIR)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Most toolchains have their libraries either in /lib or /usr/lib
relative to their ARCH_SYSROOT_DIR. Buildroot toolchains, however,
have basic libraries in /lib, and libstdc++/libgcc_s in
/usr/<target-name>/lib(64).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
With uClibc 64 bits toolchain, the dynamic loader is named
ld64-uClibc.so.0 and not ld-uClibc.so.0. So, this commit adjust the
uClibc detection code for external toolchains.
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>
Create lib64 -> lib and usr/lib64 -> usr/lib symbolic links in the
target and staging directories. This is needed for some 64 bits
toolchains such as the Crosstool-NG toolchains, for which the path to
the dynamic loader and other libraries is /lib64, but the libraries
are stored in /lib.
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>
On 64 bits glibc toolchains, the dynamic loader is named
ld-linux-x86-64.so and not simply ld-linux.so. So, adjust the
detection of the C library accordingly.
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>
Instead of copying all directories in "etc lib sbin usr", check that
each of them exists before doing the copy. This is only to avoid an
harmless error message.
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>
For the detection of the ARCH_SYSROOT_DIR (which contains the C
library variant specific to the compiler flags), we used to pass only
the -march argument instead of the full TARGET_CFLAGS. This was done
because TARGET_CFLAGS contains --sysroot, and we don't want to tell
here the compiler which sysroot to use, because we're specifically
asking the compiler where the *normal* arch sysroot directory is.
Unfortunately, there are some multilib variants that aren't decided
only based on -march, but also on -msoft-float or other compiler
flags. Therefore, we take the opposite approach: pass the full
TARGET_CFLAGS, from which we have stripped the --sysroot option.
For example, this allows a PowerPC CodeSourcery toolchain, on which
we're using the soft-float multilib variant, to work properly as an
external toolchain.
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>
External toolchains using Glibc have different names for the dynamic
loader. Some of them name it ld-linux.so.*, while some others (such as
the PowerPC and MIPS CodeSourcery toolchains) name it simply ld.so.*.
Therefore, we fix the glibc detection code to handle this case.
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>
Change the default target optimisation value so
it does not conflict with gcc optimization level
Signed-off-by: Paul Jones <paul@pauljones.id.au>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
gdbserver dlopen(3)s libthread_db.so at runtime, so there is no
dependency on it (does not appear as being (NEEDED)).
Copy libthread_db.so from external toolchain when gdbserver is enbled.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
If threads are disabled, do not try to copy the libpthread.so from the
external library.
It is still expected that the BR configuration matches the external
toolchain setup, and no check is done to enforce that.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Having a BR2_NEEDS_GETTEXT option, as introduced by
54d64798e1 isn't sufficient to express
the different kind of dependencies on gettext.
This commit, based on an idea by Peter Korsgaard, introduces two
different options :
* BR2_NEEDS_GETTEXT, which is true as soon as the toolchain doesn't
provide gettext itself (i.e, when the toolchain is uClibc based, be
it an internal or external toolchain)
* BR2_NEEDS_GETTEXT_IF_LOCALE, which is true when the toolchain
doesn't provide gettext *and* locale support has been enabled in
Buildroot.
A following commit adds some documentation that details how these
configuration variables should be used by packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Having . in the PATH makes the toolchain build process fail because it
confuses host tools and target tools.
This fixes bug #75.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Things like LD_LIBRARY_PATH=. or even LD_LIBRARY_PATH=.:/usr/lib were
not detected as incorrect.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Verify that the value of BR2_INSTALL_LIBSTDCPP set by the user in the
Buildroot configuration really matches the external toolchain
capabilities by checking that a C++ cross-compiler is available.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When using an external toolchain that uses the glibc or eglibc C
libraries, compiling a separate gettext and libintl is not needed and
is even a source of confusion, causing build failures. These build
failures are due to the fact that when libintl is compiled, it
replaces the C library libintl.h by its own, which does #define
gettext libintl_gettext. Then, when packages want to use gettext,
autoconf realize that gettext is available in the C library and
therefore do not add -lintl to the LDFLAGS, causing the build failure
because the program has been compiled to use libintl_gettext but this
function is not available.
Therefore, we should only use gettext if a uClibc internal toolchain
or a uClibc external toolchain. If an external glibc toolchain is
used, gettext shouldn't be used.
In order to implement that, we introduce the BR2_NEEDS_GETTEXT option,
which is hidden to the user, and whose value is computed automatically
from the rest of the configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When building libxcb, the variable XCBPROTO_XCBPYTHONDIR must point to
the location where the Python modules needed to run the c_client.py
program are installed. The path
$(STAGING_DIR)/usr/lib/python2.6/site-packages was hardcoded. However,
it doesn't work when the version of Python installed on the host is
Python 2.5.
Therefore, add a little bit of magic to compute the host Python
version.
We also verify that Python is available on the host, as we don't build
it in Buildroot.
Fixes bug #1531.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bash seems to be smart enough to source the file when execve returns
ENOEXEC, but other shells might not be.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
These are ancient (2006) and upstream strongly discourage using them:
ftp://sourceware.org/pub/gdb/old-releases/README
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since new configuration options have been added in 0.9.31, the value
of these configuration options should be determined, either by the
default configuration file we provide, or by uclibc.mk process.
The locale generation process should probably be improved in order to
allow building other locales than just en_US.
[Peter: fixup locale handling, add PROGRAM__NAME to defconfig]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
UCLIBC_HAS_NFTW is a new knob in 0.9.31, which allows the obsolete and
deprecated ftw() to be compiled-out separatly from nftw(), which is
part of POSIX. nftw() should probably be enabled by default in uClibc,
and a bug has been opened about this on uClibc bug tracker
(https://bugs.busybox.net/show_bug.cgi?id=1597).
nftw() is, for example, used in Gtk+.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When compiling GDB for target (in my case i386) it links
wrong BFD library from host OS. This prevents GDB from compiling
support for ELF and thus GDB is unusable on target.
More about this issue was already posted at:
http://lists.uclibc.org/pipermail/buildroot/2009-March/026585.html
Fix this issue by forcing ELF support.
Signed-off-by: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Backported a patch from CVS that improves linking times for large
projects (eg 700s to 6s). See
http://old.nabble.com/-PATCH--Reduce-ARM-linking-time-tt27961038.html
for the original.
[Peter: add patch header]
Signed-off-by: Laine Walker-Avina <lwalkera@ieee.org>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
