using slim headers-only version. this change is needed to support all
future versions of musl on 32-bit archs, since prior to 4.16 the
kernel headers had incompatibility with userspace time_t not matching
the kernel's old (32-bit) time_t. support for older headers will be
dropped entirely soon.
as maintained in https://github.com/sabotage-linux/kernel-headers .
downloading (and extracting) a 100+ MB kernel source tarball just for
the headers is extremely inefficient.
sabotage linux' kernel-headers tarball provides the same (including
musl compatibility fixes) in ~800 KB.
in order to use it, specify
LINUX_VER = headers-4.4.2-4
in your config.mak.
if LINUX_VER lacks the "headers-" prefix, the official source tarball
will be downloaded as usual.
the logic for processing the NATIVE var (shortcut for HOST=$(TARGET))
and HOST var took place before inclusion of config.mak, causing NATIVE
not to be honored and wrong BUILD_DIR and OUTPUT defaults to be used
if either was set from config.mak rather than on the make command
line. the current preferred interface is the command line, but the
regression was unintentional.
to fix it, replace the conditional blocks of the makefile with
conditional functions in recursively-expanded variables HOST,
BUILD_DIR, and OUTPUT. this way, assignments to NATIVE or HOST that
take place later in config.mak will affect the resulting values, as
intended.
cross (or native) compilers meant to be run on a host different from
the build environment can now be built by setting the HOST make
variable on the command line or in config.mak. this requires (for
building the target libraries) a cross toolchain for the same TARGET,
but that can run on the build system, to be present already in the
PATH. future enhancements may make it possible to automatically build
and use the needed toolchain.
leaving HOST blank produces a toolchain that runs on the build system
(host==build in gcc jargon), the same as before with NATIVE unset.
the NATIVE make variable is now obsolete but still supported; it
simply causes HOST to be set equal to TARGET (thus producing a native
toolchain for the target).
builds are now placed in build/$(HOST)/$(TARGET) when HOST is set, and
build/local/$(TARGET) when it's not, so that builds for the same
target but different host do not clobber each other.
default OUTPUT directory when HOST is set is now output-$(HOST). as
usual, multiple targets can safely go in the same output directory,
but toolchains for different hosts should not.
based on patch by Michael Forney, but using a plain variable without
without the need for $(call ...). I used a different name for the
variable so that it won't break if anyone has an HTTP_GET variable for
use with the original patch in their config.mak.
this is useful for preparing to automate multiple builds using shared
source trees. otherwise concurrent builds could clash attempting to
extract the same source trees.
this feature is still experimental and requires manually setting a
LINUX_ARCH make variable matching the target. automatic mapping will
be added later. if LINUX_ARCH is not set, header installation is
skipped.
this allows sharing a sources directory between multiple checkouts or
independent toolchain-using projects.
also, during distclean, only remove the in-tree sources directory, not
a custom/external one. this is a safety measure in case the SOURCES
variable is set to something stupid like blank, root directory, or
some large shared directory.
this makes it easy to rebuild components simply by removing the source
or build directory with rm -rf; no separate action on the steps files
is needed.
some dependencies are also changed to order-only so that
update/rebuild of one component does not force unnecessary rebuild of
another.
new convenience pseudo-targets are also added.
old versions of gcc, such as 4.2.1 which I'm in the process of adding
support for, have broken configure scripts that do not accept
variables on the command line and instead interpret them as the target
name. the easiest solution is just passing these in the environment.
previously the stage0 gcc was installed to the output location during
the build, then replaced later by the final gcc. this violates the
principles of make and simply wastes time. the stage0 gcc is usable
in-place without installing it, so we can simply do that instead.
Rich Felker
rofl0r
Michael Forney
Szabolcs Nagy
Patrick Oppenlander