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.
This is not needed since we already have a native musl toolchain at our
disposal. Previously, since this flag was passed for NATIVE=1, the build would
fail because the build sysroot is only built for cross toolchains.
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.
These files aren't useful, especially for a toolchain meant to be
relocated, because they contain references to the staging directory
and source paths.
this patch breaks powerpc64 builds and is not necessary to produce a
working 32-bit powerpc toolchain. it seems like it may be useful for
reducing libgcc-internal bloat, but it can be reintroduced later after
it's fixed, if desired.
upstream fix was slightly too late to make it into the release. patch
was not included in mcm for previous binutils versions because it
depends on new upstream infrastructure. now gc-sections should be safe
to use on sh.
LC_ROOT does not seem to have any useful effect, but the
build sysroot is passed to shell scripts without expanding
the LC_ROOT make variable which breaks tests.
the += approach which worked in config.mak does not work well if the
user wants to pass in configure options from the command line.
restructure configure command line construction such that setting
COMMON_CONFIG, GCC_CONFIG, or TOOLCHAIN_CONFIG from the command line
does not suppress necessary defaults.
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.
commit 20ce424e65 introduced a situation
where two instances of gcc's build process could be invoked
concurrently in the process of fixing the same issue for musl. only
the production of native compilers seems to have been affected. add a
direct dependency edge rather than relying on the indirect dependency,
which was only present in non-native mode.
these are not needed since the cross toolchain being used to build the
native compiler already has its own libc and headers.
but more importantly, due to lack of certain dependency chains that
would be present for a cross compiler build, it was possible for two
invocations of musl's make process to occur in parallel (one for temp
sysroot headers, one for actual libc build). this could (and was
observed to) lead to a race condition where alltypes.h was momentarily
truncated in the middle of the libc build.
commit 03bd65562a wrongly placed the
logic conditional on $(TARGET) before inclusion of config.mak, so that
it only worked when TARGET was set from the make command line or
environment. reorder to fix.
Rich Felker
Rich Felker
Michael Forney
Patrick Oppenlander
Dhiru Kholia
rofl0r
Szabolcs Nagy