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 default is ordered such that user-provided config variables in
config.mak or on the make command line can still override it.
this is a dubious anti-ROP feature with high cost (file size, load
time, VMA count consumed per library), and historically was broken in
some binutils versions. the ones we use don't seem to be affected, but
it's better to have it off anyway.
new patch: 0017-c++-abi-break.diff fixes a C++ ABI break regression.
0010-static-pie-support.diff was removed as it doesn't apply anymore,
and forward-porting it requires arcane knowledge of GCC details.
the patches 0018 and 0019 have been copied from GCC 7.3.0. the static
pie patch from GCC 6.4.0, renumbered 0020, depends on the reversions
they make.
When the gcc and binutils build trees were separated in defdbb4505,
--enable-deterministic-archives was accidentally left in FULL_GCC_CONFIG.
This had the effect of reverting commit e83fe4b8ce, breaking
reproducible builds (unless it was specified explicitly in config.mak).
Originally added in commit 40d6414f28,
the purpose of the above target definitions was to allow using the
static-only symlink variant of slibtool (i.e. slibtool-static) in
those build steps which required it. Given slibtool's newly added
ability to auto-detect its desired operation mode (shared-only,
static-only, or both), as well as the integration of rlibtool
support in mcm, the aforementioned explicit target definitions
are no longer needed.
Beginning with slibtool version 0.5.26 and the introduction of the
rlibtool symlink (the equivalent of slibtool --heuristics), slibtool
may now be told to automatically detect its desired operation mode
(share-only, static-only, or both) by way of parsing the generated
libtool script which it replaces.
the initial-exec tls model is not valid in any code that might be
dynamically loaded. it usually happens to work on glibc because glibc
reserves some static tls space for late-loaded libraries that need it,
but if it's already been exhausted that will fail. musl does not
support this hack at all, and it's not valid for gcc target libs to be
doing it anywhere, so patch it out entirely rather than just for musl.
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.
Generated from within gcc, the above dependency libraries are built with the
--disable-shared libtool option. As with binutils, distinct build steps for
each of the above in litecross/Makefile allow for their correct (static only)
generation by an alternate libtool utility, such as slibtool.
these are not complete/correct in that they do not account for ABI
variants (softfloat and coldfire fpu) in the dynamic linker name, but
I was unable to get gcc's configure to accept --with-float=soft on
m68k to test softfloat and begin figuring out how to do the spec
logic. at some point this needs to be figured out and completed, but
at least the default ABI is available in mcm now.
GCC 6.4.0 has one big advantage over 6.3.0: it is shipped as .tar.xz,
shaving 30 MB from its download size, and also considerably speeding
up the extraction process.
All patches are copies of the GCC 6.3.0 ones, except
0004-posix_memalign.diff which was rebased to apply cleanly.
0014-ubsan-empty-string-fix.diff was removed, since it was upstreamed.
musl uses IEEE quad for long double on s390x. current versions check
for mismatch and hard fail at configure time if the compiler is wrong.
with older versions, mcm silently produced a broken toolchain/libc.
putting them together in one tree only works if they're "sufficiently
close" in version, due to each needing (approximately) its own version
of libiberty and possibly the top-level configure infrastructure.
eventually, I want to stage the installs of binutils and gcc under the
build directory, so that the new binutils can be used from their
staged install paths. leave that refactorization for later; for now,
give gcc the binutils it needs directly out of the binutils build
directories.
the linker was wrongly leaving dynamic relocations for GD-model TLS
defined in the main program when linking the main program as PIE. this
was only suboptimal for dynamic pie, but for static pie it resulted in
runtime failure since there is no dynamic linker to resolve the DTPMOD
reference.
this has been reported as binutils bug #22570.
'aarch64' is converted to 'arm64' in the TARGET_ARCH_MANGLED assignment,
but then LINUX_ARCH is set the first to the first linux arch which
appears in TARGET_ARCH_MANGLED. Since 'arm' is a substring of 'arm64'
and appears ahead of 'arm64' in sorted order, it gets chosen
incorrectly.
To fix this, use 'lastword' instead of 'firstword'. This should work for
all current linux architectures, but is still not perfect in the
theoretical case where the substring match is not rooted at the
beginning of TARGET_ARCH_MANGLED. So, also replace 'findstring' with an
'if' and 'filter'.
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.
binutils' ar program defaults to creating timestamp in archives, which
breaks reproducible builds.
this misfeature can be explicitly turned off on every usage (-D), or be
disabled completely at build time using the --enable-deterministic-archives
option.
since the former requires patches for every package, having the toolchain
doing the right thing by default seems to be the much better choice.
the configure option is available since binutils 2.20, so it should be
safe to use by now.
Rich Felker
rofl0r
Kevin Mark
rofl0r
Michael Forney
midipix
luca
Szabolcs Nagy
Rich Felker
Patrick Oppenlander
Dhiru Kholia