coreutils: add 'join' to the list of files that are copied to target
rootfs.
Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The cleanup of $(TARGET_DIR)/usr/share/man, $(TARGET_DIR)/usr/man,
$(TARGET_DIR)/usr/share/info, $(TARGET_DIR)/usr/info,
$(TARGET_DIR)/usr/share/doc and $(TARGET_DIR)/usr/doc is already done
globally in the main Makefile. Therefore, there's no need to handle
that on a per-package basis.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Those are already in TARGET_CONFIGURE_ARGS. Also get rid of unused
BR2_AC_CV_FUNC_MALLOC_0_NONNULL variable.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We were patching m4/rename.m4 to workaround an upstream issue, but this
triggers a auto* rebuild and a configure rerun when we build coreutils
using whatever auto* versions the user has installed.
Doing a manual autoreconf run after patching is unfortunately not an
option as the coreutils configure.ac isn't compatible with the autotools
version we have in BR.
Instead, simply cheat by patching configure as well and setting the
timestamp of m4/rename.m4 sufficiently far back to ensure make doesn't
consider ./configure out of date.
Long term we should convert coreutils to Makefile.autotools.in format,
but this is good enought for 2009.11.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We have been passing -q to ./configure when using 'make -s' for
packages using Makefile.autotools.in for some time. Do the same
for packages using autotools, but not using the
Makefile.autotools.in infrastructure, taking care to not do it
for packages with hand written configure scripts.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The variable controlling if coreutils thinks the system has the
rename-with-trailing-slash bug is called
gl_cv_func_rename_trailing_slash_bug and not vb_cv_..
Forcing this off works around a bug in coreutils configure, which
otherwise tries to compile Windows-only workaround code.
Reported-by: Stephen Rodgers <hwstar@rodgers.sdcoxmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
A C library will have been built by the toolchain makefiles, so there is no
need for packages to explicitly depend on uclibc.
Signed-off-by: Will Newton <will.newton@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Coreutils 6.9 was broken with glibc >= 2.6, due to a coreutils
internal function being named like a glibc function. This has been
fixed in more recent coreutils version, by
http://lists.pld-linux.org/mailman/pipermail/pld-cvs-commit/Week-of-Mon-20070514/155466.html.
Therefore, we upgrade coreutils to its latest version, 7.4, which
raised two problems:
* Recent coreutils releases are not anymore available as .bz2
archives, only .xz archives. Since this archive format is not
supported by Buildroot yet, and the corresponding tools are not
widely available yet, we fallback to the bigger .gz format for the
coreutils package.
* The rename bug detection script m4/rename.m4 was broken, leading
coreutils to try to include windows.h and compile some
Windows-specific code. We introduce a patch to fix this, patch
which has been taken from gnulib. We also make sure that this
workaround is nevery compiled in by passing
gl_cv_func_rename_dest_exists_bug=no to the configure script.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
they should be configured with --prefix=/usr and we then need to use
make DESTDIR=$(STAGING_DIR) install to get things installed into the
staging directory. The current situation for many packages, which use
--prefix=$(STAGING_DIR) results in the staging_dir paths getting compiled
into the binary itself.
This also adds in a pile of libtool fixups. Between broken pkgconfig,
broken libtool handling, and broken --prefix settings, its a wonder
things have worked as well as they have up till now.
-Erik
in the interest of our younger readers>. This works around some of the
worst damage, thus allowing utils such as 'df' to properly cross compile
so that ltp will produce proper results.
