previously zig would look for all the .defs even when not needed,
wasting time. also, we only had samsrv definitions for some architectures.
remove cross compiling support for this.
Clang pretends to be gcc 4.4 and that causes some re-definition errors.
The problem has been reported to the upstream some time ago but nothing
was done about it.
From: Szabolcs Nagy <szabolcs.nagy@arm.com>
armv8 removed the coprocessor instructions other than cp14, so
on an armv8 system the related hwcaps should never be set.
new llvm complains about the use of coprocessor instructions in
armv8-a mode (even though they are never executed at runtime),
so ifdef them out when musl is built for armv8.
<dalias> i think the patch looks ok
It was using __GNUC__ < 8 to check if _xgetbv intrinsic is available.
Since we always use zig cc with this header, we know we have clang 9,
which does have this intrinsic.
The previous
[instructions](https://github.com/ziglang/zig/wiki/Updating-libc) for
updating musl libc headers had this (repeated for each architecture):
make DESTDIR=build-all/arm install-headers ARCH=arm
However musl's build system does not properly rebuild alltypes.h and
syscall.h from source, instead using whatever is cached from the
previous build. In the case of the previous time that I updated to musl
1.1.23, this happened to be the aarch64 architecture.
As a workaround, one can remove the obj/ directory to force rebuilding
this file. Now the instructions say this (repeated for each architecture):
rm -rf obj/ && make DESTDIR=build-all/arm install-headers ARCH=arm
This commit updates the resulting headers after this workaround is
applied and the process headers tool is run again.
Upstream commits:
* 8eb49e0485fc547eead9e47200bbee6d81f391c1
* 2dcbeabd917e404a0dde0195388da401b849b9a4
* f0eb2e77b2132a88e2f00d8e06ffa7638c40b4bc
These will be in the next version of musl, so no harm carrying them
here.
also start prefering NtDll API. so far:
* NtQueryInformationFile
* NtClose
adds a performance workaround for windows unicode conversion. but that
should probably be removed before merging
