Cherry-picked from upstream:
https://git.savannah.gnu.org/gitweb/?p=config.git;a=commit;h=1c4398015583eb77bc043234f5734be055e64bea
Everything except external/apache2/llvm/dist/llvm/cmake/config.guess
is patched, which is under vendor tag and cannot be modified. I expect
that this file is not actually used as we use hand-crafted version of
configure script instead of cmake for building LLVM.
Note that external/apache2/llvm/autoconf/autoconf/config.guess has
already been committed on Oct. 20, but commit message disappeared as
cvs aborted due to "permission denied" when trying to modify the file
mentioned above. Sorry for confusing you.
Also note that GMP uses its own config.guess Patch for
external/lgpl3/gmp/dist/config.guess is provided by ryo@. Thanks!
has failed, in the hope that some other thread has free'd some memory,
but we want to bound the number of attempts, it helps if we actually
count them - otherwise we never get nearer to the limit.
In practice, malloc() for a reasonable application on a modern system
almost never fails, so the code containing this bug has probably never
been, and never will be, executed, but just in case, someday.
For this, it isn't clear if the intent was to have 10 retries (ie: 11
attempts) or 10 tries, but as the code said "retries > 10", I am
assuming the former (not that it matters, if the malloc() has failed
10 times in a row, with 10 second pauses between, the chances of an
11th succeeding aren't great).
GCC_NO_FORMAT_TRUNCATION -Wno-format-truncation (GCC 7/8)
GCC_NO_STRINGOP_TRUNCATION -Wno-stringop-truncation (GCC 8)
GCC_NO_STRINGOP_OVERFLOW -Wno-stringop-overflow (GCC 8)
GCC_NO_CAST_FUNCTION_TYPE -Wno-cast-function-type (GCC 8)
use these to turn off warnings for most GCC-8 complaints. many
of these are false positives, most of the real bugs are already
commited, or are yet to come.
we plan to introduce versions of (some?) of these that use the
"-Wno-error=" form, which still displays the warnings but does
not make it an error, and all of the above will be re-considered
as either being "fix me" (warning still displayed) or "warning
is wrong."
Formerly rump kernels treated the two types of mutexes as both adaptive for
LOCKDEBUG for some reasons.
Now we can detect violations of mutex restrictions on rump kernels such as
taking an adaptive mutex with holding a spin mutex as well as normal kernels.
This paves the way to resolve rump build process using buildrump.sh, where the definition of
HAVE_REGISTER_T caused conflicting definitions of register_t.
introducing since release of software to be recognised. This should hopefully
allow the builds to progress a littles further on systems such as the POWER8
which features a little endian 64-bit PowerPC CPU identified as ppc64le.
..$RANDOM won't work with our /bin/sh.
unsure if this script is used, but it is wrong.
might help the spurious build failures that occasionally
show up on autobuilds.
At least GNU Hurd lacks MAXHOSTNAMELEN/MAXPATHLEN/PATH_MAX, so make sure
those have some arbitrary semi-sane values.
from Robert Millan in PR misc/50166, with some modifications from myself
to unwind the stack. Add a temporary workaround where we simply don't
allow the thread to exit (a kernel thread exit is a relatively uncommon
event in a rump kernel anyway).
namely:
* src/lib is used only when building for POSIX'y platforms, but
the man pages have their use for all platforms
* rumpuser.3 is a function of the rump kernel, not one of the of
the POSIX'y implementation hosted in src/lib/librumpuser
no functional change
rin