Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

The makefile uses pkg-config for libxml2 support.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

TARGET_CONFIG_ENV got removed in e721a7c0 (Merge TARGET_CONFIGURE_ENV
into TARGET_CONFIGURE_OPTS), so remove it from the recent libsvgtiny
package as well.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

Version 1.41.12 was released May 18, 2010.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

The bzip2 make install target follows symlinks, so if busybox is
enabled and the bzip/bunzip2 applets are installed, bin/busybox will
get overwritten by bzip2.

Fix it by ensuring any previously installed bzip2/bunzip2/bzcat (the
applets available in busybox) are removed before running make install.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

Signed-off-by: Darius Augulis <augulis.darius@gmail.com>

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

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>

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

TARGET_CONFIGURE_ENV defines CFLAGS, LDFLAGS, CXXFLAGS and FCFLAGS,
separatly from all other variables that are part of
TARGET_CONFIGURE_OPTS. This is useless and not consistent with the
HOST_CONFIGURE_ variables, therefore we merge TARGET_CONFIGURE_ENV
into TARGET_CONFIGURE_OPTS and fix the few users of
TARGET_CONFIGURE_ENV.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

We now have for quite some time a configuration cache used to speed-up
the execution of ./configure scripts when compiling programs for the
target. This commit introduces a similar concept when Buildroot
compiles programs for the host.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

These shouldn't be needed. Even when the cross-compiler is in
$(STAGING_DIR)/usr/bin, we anyway use an absolute path for TARGET_CC,
TARGET_LD and al.

Not having $(STAGING_DIR)/{usr/bin,bin} in the PATH will avoid having
Buildroot trying to run target binaries.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Those variables are not standard.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

The definition of CC, LD, GCC, CPP, CXX and FC shouldn't contain the
CFLAGS/LDFLAGS/CXXFLAGS, those should be passed through the
appropriate variables.

However, the --sysroot option is a particular case here: it needs to
be part of the CC/LD/GCC/etc. definitions otherwise libtool strips it
from the CFLAGS/LDFLAGS.

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>

Just as we did for LD/LDFLAGS, pass CFLAGS and CXXFLAGS in their own
variables.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

When building packages for the host, the *_FOR_BUILD and *_FOR_TARGET
variables are not needed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

We build host tools installed in $(HOST_DIR)/usr/bin, and some of them
rely on host libraries in $(HOST_DIR)/usr/lib. So when these host
tools are executed, they need to find the host libraries, which are
not installed in a default location.

In c1b6242f we tried to use
LD_LIBRARY_PATH when building target packages to solve this
problem. Unfortunately, LD_LIBRARY_PATH is not only used to find
libraries at run-time, but also at compile time. So it leads the build
of some packages, such as icu, to fail.

Therefore, in 0d1830b0, we reverted
the LD_LIBRARY_PATH idea.

The other option to solve this problem was to hardcode a RPATH value
in the host binaries that would reference the location of host
libraries. We added this -Wl,-rpath option to HOST_CFLAGS in
6b939d40. Unfortunately, this caused
problems when building binutils, as reported in bug 1789 so this
change was reverted in e1a7d916.

Then, we tried to use -Wl,-rpath in HOST_LDFLAGS, but it was causing
problems with fakeroot not recognizing 'ld' as the GNU linker, since
the -Wl,-rpath cannot be understood by 'ld' directly, only by 'gcc'.

This commit is a new attempt at using HOST_LDFLAGS, but in this case
we modified the definition of HOST_LD to *not* contain
HOST_LDFLAGS. LDFLAGS are being set separatly. It solved the fakeroot
issue and was tested against nearly 300 packages of Buildroot.

For more details on this story, see
 http://lists.busybox.net/pipermail/buildroot/2010-June/035580.html
 http://lists.busybox.net/pipermail/buildroot/2010-June/035581.html
 http://lists.busybox.net/pipermail/buildroot/2010-June/035586.html
 http://lists.busybox.net/pipermail/buildroot/2010-June/035609.html
 https://bugs.busybox.net/show_bug.cgi?id=1789



Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

The existing cross-compilation patch works with our not completely
correct TARGET_CONFIGURE_OPTS. With the correct variables (CFLAGS,
LDFLAGS) being passed, fontconfig was trying to use target
CFLAGS/LDFLAGS when building tools for the host.

This updated patch fixes that problem by correctly using the
CC_FOR_BUILD, CFLAGS_FOR_BUILD variables.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Passing LDFLAGS/CFLAGS when building for the host allows cmake to be
compiled with the proper -rpath value (the -rpath option is added to
HOST_LDFLAGS in a later commit).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Thanks to Thomas for noticing.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

As it doesn't use a ./configure, we need to pass it each time.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

And fix the .mk file name while we're at it.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

Closes #2143

Fixes crash on static linking without stdio / x86. Both patches are from
upstream uClibc.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

ruby is converted to the autotools infrastructure, and the dependency
on host-ruby is added since a ruby interpreter is needed to build a
ruby interpreter. Fortunately, this is taken into account in the ruby
build process, and it first start to build a mini-interpreter that is
used to build the rest. However, this doesn't take the
cross-compilation case into account, so we have to build ruby for the
host.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

The .mk file was hacking the CC_FOR_BUILD value so that
$(STAGING_DIR)/usr/include is added to the include path. This is not
correct since $(STAGING_DIR) contains target stuff, not host
stuff. The correct fix is to add a dependency on host-xproto_xproto,
which will install the needed headers in $(HOST_DIR)/usr/include.

In addition to that, a patch is added to make xlib_libXt build system
behave properly in the cross-compilation case, where the makestrs tool
needs to be built on the host as part of the compilation process. This
was working before because of our quirky TARGET_CONFIGURE_OPTS, but
those are going to be fixed in a future commit.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

gperf on the host is needed, since it is used by xcb-util to generate
a perfect hash function.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Webkit depends on libjpeg, so add it as a dependency. Webkit also uses
icu but fails to find it if we don't pass ac_cv_path_icu_config to its
./configure script.

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>

The patch is already in upstream uClibc, in the master branch, at
http://git.buildroot.net/uClibc/commit/?id=6f1daaaf2d94c1e6184add44eda38b0781b88cf0

.

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>

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>