I overlooked that GCC was not doing this by default for musl, since
binutils ld automatically converts the .ctors/.dtors GCC emits to
init/fini arrays at link time. unfortunately lld does not do the same,
so without --enable-initfini-array, GCC produces object files that lld
will mislink unless it was configured with support for legacy GCC
ctors.
gmp does not build correctly with compilers that default to emitting
PIE/PIC, due to custom-preprocessed asm source files which have wrong
logic for determining if PIC-compatibility is needed. ideally this
would be patched in gmp, but I don't know how to do that, so for the
time being, just disable the asm.
now that config.guess knows how to detect musl, it's possible when
building on a musl-based system that $build will spuriously match
$target, preventing the desired behavior of building as a cross
compiler or as a cross-compiled native compiler.
run config.guess and config.sub from the litecross makefile to check
if $build is going to match $target, and if so, append junk to the
libc/abi part of the $build tuple so that it no longer matches.
this should be a nop since we're either building a cross compiler or
cross compiling, but due to recent gcc's config.guess detecting musl,
it's possible to spuriously get $build=$host=$target, and then the
dreaded bootstrap procedure runs and breaks the output.
the value should only be the root, not including the .c suffix. as
noted in commit 2d0015f547 which added
this, the result is not actually used, so it doesn't matter that it's
wrong, but the wrong value produces spurious error output in configure
logs.
with the default --enable-libstdcxx-time, libstdc++'s configure probes
for the existence of a clock_gettime syscall and sets up the time API
implementation to make direct syscalls, presumably as a workaround for
old glibc tucking away the clock_gettime function in librt, which in
turn depends on libpthread. this breaks since struct timespec does not
match the syscall's interface on 32-bit archs.
passing --enable-libstdcxx-time=rt forces different configure paths
that correctly use the public clock_gettime function and librt if
needed.
this issue should be patched in gcc rather than worked around via
configure options, but I'd rather wait to patch until I understand how
to fix it correctly and produce a patch that's acceptable to upstream
and distros.
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.
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.
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.
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.
'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.
These files aren't useful, especially for a toolchain meant to be
relocated, because they contain references to the staging directory
and source paths.
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.
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.
leaving necessary configuration options for certain targets to the
user is error-prone and inconvenient. instead of configuration for
exact target string matchs in the sample config.mak, provide general
logic in the makefile itself which should cover all variants as well.
I didn't realize before but, using the O make variable, kernel source
can do out-of-tree builds, making it safe to use a symlink rather than
partial copy for the source dir. the partial copy did not work for all
archs; in particular x86 was broken.
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.
libmpx is broken in all gcc versions that have it (not supported yet
by mcm/litecross, but will be).
ifunc is not supported by musl and won't be unless/until the contract
for resolvers can be specified clearly in a way that real-world usage
is safe and does not require lazy binding; having it enabled at gcc
level reportedly produces a broken libatomic.
explicitly enabling libstdcxx-time is needed to get libc clock_gettime
(with vdso support) to be used in libstdc++; it's disabled by default
because of glibc legacy practice of having clock_gettime in librt,
which depends on glibc's libpthread and undermines libstdc++'s
(invalid use of) weak references to pthread symbols.
others are untested and some are likely broken. add this config option
before including config.mak rather than after so that the user can
override it in config.mak if desired.
multilib would not be usable without building multiple versions of
musl anyway, which we don't yet support, so enabling it does not make
sense. due to bugs in gcc's build system, even with multilib disabled,
multilib dir structures get used on 64-bit archs leading to target
libs being installed in /lib64 (or /libx32, etc.) under the sysroot,
rather than /lib. fix this by suppressing the variable that controls
it.
blanking INFO_DEPS suffices to prevent attempts to rebuild the docs,
but does not reliably suppress their installation. blanking infodir
does the latter. there are other methods that work too but this seems
to be the simplest.
nothing in a normal gcc/binutils actually uses flex and bison, but
this useless test for the output filename lex produces breaks the
build unless [f]lex is installed. the result of this check is
specified by posix anyway, so hard-code the specified result.
Rich Felker
Michael Forney
midipix
Rich Felker
rofl0r
Szabolcs Nagy
Patrick Oppenlander