The previous fix ensured that objtool was built for the right host
architecture, but it was still including some UAPI header files
(in particular <asm/bitsperlong.h>) for the build architecture.
Currently we replicate the mapping of Debian architectures to kernel
source architectures here. Use the KERNEL_ARCH variable that is now
passed down by rules.real. We still need to check whether perf is
supported on the architecture, though.
- Introduce linux-bootwrapper-<abiname> package containing boot wrapper
tools for the host architecture
- linux-image: Install symlinks to boot wrapper tools instead of the
native tools built by kbuild
objtool is normally built and used during the kernel build process,
in which case it should always be built as a native executable.
But when we build it for linux-tools it should match the target
architecture. We need to override the CC and LD variables to
make this work.
It has a lintian error (non-empty-dependency_libs-in-la-file) and it
also seems to be missing a header (the newly added
usbip_host_common.h) since Linux 4.7. No-one seems to have noticed,
and it has nothing build-depending on it, so get rid of it.
This reverts commit 85b468262e "Remove unused liblockdep packaging"
and 87d08943da "liblockdep: Stop trying to build packages, as it
failed to build again", but doesn't restore the patches. All our
patches, and further build fixes, were applied upstream as of
v4.13-rc1.
Commit cf0c3e68aa81 "kbuild: fix asm-offset generation to work with clang"
changed the macros used by devicetable-offsets.c. Copy the new sed code
from upstream scripts/Makefile.lib.
Currently the linux-source-<version> package may or may not include
these files, depending on the order things are built in.
As autotools always modifies the source directory, copy (rsync) the
source to the build directory and build in-place there.
Some years back I patched the #include of <linux/usbip.h> to include
the current, uninstalled version through a relative path because the
system-installed version will normally be outdated. We're about to
start copying the source to avoid writing autotools crap into the
source directory, which breaks this relative path.
Since we now install the UAPI headers under debian/build at the start
of the tools build, drop the patch and add that directory to the
include path.
Drop rt patchset updates as they don't apply to 4.7.
Drop various other patches already in 4.7.
Fold the remaining Debian changes in the open changelog entry for 4.6.7-1
into the open changelog entry here.
Pass $(CROSS_COMPILE) or host GNU type through to upstream build rules.
debian/rules.real: Filter tools packages by host arch, not build arch
debian/rules.d/Makefile: Build the tools needed for headers_install in
a separate subdirectory
Currently we build-depend on the native python (via asciidoc), and on
the host python (via python-dev). As these are not coinstallable it
is impossible to perform a complete cross-build. Until that's resolved,
this will allow cross-building of most of the package with the
combination of the 'cross' and 'nopython' profiles.
(This also sidesteps the issue of perf wanting a multilib compiler.)
Martin Michlmayr found that userland builds fail if 'uname -m' reports
the native kernel architecture, and that's because we don't explicitly
set ARCH for the headers_install target. That's fine for most cases
of a 32-bit chroot on a 64-bit kernel because a single source
architecture covers both, but arm/arm64 is an exception.
This doesn't make actual cross-builds of userland tools work.
* Rename the make macro from submake to make-tools
* Rename debian/stamps/build to debian/stamps/build-tools
* Build them all under debian/build/build-tools/
Add installdir variable that defaults to $(prefix)/$(OUTDIR) as used
in scripts/, but can be set directly in tools/hv which doesn't want
to mirror the source hierarchy.
Ben Hutchings
Uwe Kleine-König