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.
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.
rofl0r
Szabolcs Nagy
Rich Felker
Michael Forney
Filippo Valsorda
Rich Felker
Patrick Oppenlander