Remove 'strace-fix-arm-bad-syscall.patch'. This patch had been integrated
in v4.6 (commit: 9bc6340d2) and was later replaced with a generic solution
in v.7 (commit: 2ce12ed31c2).
Strace still cannot handle non-LFS environments, so a modified version of
strace-fix-disabled-largefile-syscalls.patch remains. The 64-bit syscalls
(sys_truncate64, etc.) are references in the sysent structure but the
functinon definitions are commented out becuase of the missing LFS support.
The workaround for the 'forced lfs mode' doesn't seem to be necessary anymore.
Build tested on arm w and w/o LFS support.
[Peter: arc still not supported]
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
strace fails to build on x86_64 because stat64 is not available. This
is because the automatic detection of stat64 in configure is overridden
by buildroot, by setting ac_cv_type_stat64. Just remove that override -
current strace seems to detect it correctly for non-largefile platforms.
Build-tested on x86_64 (with largefile), ARM (with and without largefile),
sh4, MIPS and ppc-32 (no largefile).
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Thanks to the pkgparentdir and pkgname functions, we can rewrite the
AUTOTARGETS macro in a way that avoids the need for each package to
repeat its name and the directory in which it is present.
[Peter: pkgdir->pkgparentdir]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
It's really not very useful, all it does is install a target
strace and ldd in a target_utils directory in staging.
While at it clean up the strace makefile a bit.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
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>
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.
- Force detection of these in configure by supplying environment
variables
For them to be detected by configure may require a much more
invasive approach by patching configure.ac and regenerating
apon build.
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
