gmp has its own wrapper version of this file and calls the real one
configfsf.sub. within the gcc build, replacing the wrong one is
harmless, but it breaks independent use of the patched gmp tree and
it's logically wrong.
patch by Laurent Bercot.
reportedly the vdso version of clock_gettime64 produces erratic
results on arm with linux 5.6, and earlier versions did not have the
vdso function at all. it's not clear what the eventual upstream
solution will be, but something needs to be done so as not to be
producing binaries that seem to work now but will break fantastically
when moving to newer kernels.
PWD is set by the shell, not make, and might not match.
For example, this broke the build through Homebrew, because
PWD stays at the directory where brew is ran.
previously this was missed because there's target-specific spec magic
for a few targets to do it, but many including arm don't have it.
without this, use of -static-pie produces broken binaries which lack
an interpreter but link to shared libraries on the targets affected.
use of -static -pie (preferred form) is not affected. gcc versions
prior to 8.x did not have -static-pie (because there was no upstream
static pie support) so this patch is only needed for 8+, and only to
prevent breakage if someone uses the -static-pie option instead of
-static with -pie.
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.
approach in commit 8a92c5230c only
worked for the "current version" of the packages configured with
GCC_VER, etc. now, all versions have proper dependencies so that it's
possible to test applicability of new patches just by running make
with the directory name.
these are needed for time64 compatibility, and are backported from the
y2038-endgame kernel branch and squashed with non-uapi changes
removed.
with just these patches applied the kernel will not build since
changes at the source level are also needed. but it is not practical
to backport source changes to an old kernel, and even if it were, it
would not make sense to include irrelevant changes that need rebasing
in a patchset intended only for the purpose of uapi header
installation.
forward-ported from the now-removed 4.4.10 patch, needed to fix#8,
spurious dependency on host elf.h header. I checked x86 and mips which
seem to be the only archs with archscripts rules, and these rules have
nothing to do with building headers, so omitting them should still be
safe.
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.
error out if there are any slashes in the name that will later be
passed to rm -rf since these are implicit rules and could
theoretically get instantiated in unintended ways.
As part of creating a CoW source tree, we symlink all top-level paths
from the original directory. In commit ebf93035c, we removed a shell
glob used for this and replaced it with an invocation of `find`.
However, our invocation of `find ... -exec sh -c '... $@ ...' {} \+`
is causing the first path in every directory to be skipped, breaking
the build. This is because arguments to `sh -c ...` begin with the
zeroth argument, while `$@` only returns the first argument onward.
Let's fix this by providing an explicit zeroth argument to `sh -c`.
shell glob of ../$</* fails to catch filenames beginning with dot, and
the easy mitigations for that all produce bad results on non-match.
use find to do it robustly.
this makes it far easier to iterate testing of patches, and sets the
stage for enforcing re-patching with makefile-level dependencies.
the pristine sources are kept in directories suffixed with ".orig",
and the unsuffixed directory now contains the result of running
cowpatch -- that is, a mix of symlinks to the original files, and
modified copies of the files/directories affected by patches.
After discussion with Rich Felker and other contributors, it's clear
that we want to license this project under the MIT/Expat license.
However, we need to be clear that we're not claiming to license the
binary artifacts, as those retain the licenses of the upstream
projects. Similarly, the patches, to the extent that there is any
copyright interest in them at all, retain the licenses from the
upstream projects.
We've added language in the README and in a new `COPYRIGHT` file to
make all of this clear.
Ref: #25#30#80
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.
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.
both 4.19.90 from official kernel tarball and 4.19.88 from the
sabotage-linux headers-only package are added. the latter should be
preferred unless you have a reason not to, as it's much smaller and
has some patches that improve interaction with musl.
support for all earlier kernel header versions will be dropped soon,
since everything prior to 4.16 has incompatibilities with 32-bit archs
moving to time64.
this is binutils issue 23825, but it's caused by gcc using local-exec
model rather than initial-exec model with the intent of making
binutils generate copy relocations. this is harmful, unnecessary, and
not presently supported by musl (and probably should never be). patch
taken from https://github.com/riscv/riscv-gcc/pull/118.
Rich Felker
Peter Jin
Filippo Valsorda
Travis Cross
Andrew Chambers