| Age | Commit message (Collapse) | Author |
|---|
|
Closes #18257.
|
|
Closes #23795.
|
|
|
|
|
|
|
|
|
|
|
|
The Lua headers are needed because, yes, NetBSD has a kernel module for Lua
support. soundcard.h is technically a system header but is installed by
libossaudio and so was missed previously.
This also removes some riscv headers that shouldn't have been added because
NetBSD does not yet officially support the riscv32/riscv64 ports.
Closes #24737.
|
|
|
|
|
|
* getrandom was added in glibc 2.25
https://sourceware.org/bugzilla/show_bug.cgi?id=17252
* copy_file_range was added in glibc 2.27
https://sourceware.org/git/?p=glibc.git;a=commit;h=bad7a0c81f501fbbcc79af9eaa4b8254441c4a1f
* threads.h should not exist for glibc < 2.28
* single_threaded.h should not exist for glibc < 2.35
* Apply suggestions from code review
Co-authored-by: Alex Rønne Petersen <alex@alexrp.com>
* 2.35 instead of 35
* before 2.35 instead of 2.34 and before
---------
Co-authored-by: Alex Rønne Petersen <alex@alexrp.com>
|
|
|
|
`libc`: Merge header directories for glibc and NetBSD libc where applicable
|
|
More target coverage in the module test matrix
|
|
|
|
Manual patches:
* lib/libc/include/csky-linux-gnu/gnu/{lib-names,stubs}.h
* lib/libc/include/powerpc-linux-gnu/bits/long-double.h
Takes lib/libc/include from 115.5 MB to 113.4 MB.
Closes #21258.
|
|
These were not intended to be included as NetBSD's RISC-V port has not had an
official release yet.
|
|
sys/param.h was manually adjusted to not define __NetBSD_Version__ since it will
be defined by the compiler.
|
|
|
|
osreldate.h and sys/param.h were manually adjusted to not __FreeBSD_version
since it will be defined by the compiler.
|
|
|
|
https://sourceware.org/bugzilla/show_bug.cgi?id=32776
|
|
* https://sourceware.org/bugzilla/show_bug.cgi?id=32786
* https://inbox.sourceware.org/libc-alpha/87zfhpfqsm.fsf@oldenburg.str.redhat.com
|
|
|
|
|
|
|
|
Unfortunately some duplicate files must remain in lib/libc/wasi/libc-top-half
because they include internal headers *in the same directory* which have edits
relative to upstream musl. Because C is an amazing language, there is no way to
make it so that e.g. upstream musl's src/stdio/fputc.c includes wasi-libc's
src/stdio/putc.h instead of the upstream putc.h. The preprocessor always
searches the current directory first for quote includes.
Anyway, this still takes us from 2.9M to 1.4M for the combination of
lib/libc/wasi and lib/libc/include/wasm-wasi-musl, so I still call it a win.
|
|
|
|
glibc 2.41
|
|
They were introduced in glibc 2.27
|
|
|
|
They were introduced in 2.36 & 2.39
|
|
|
|
It was added in glibc 2.28
|
|
It is only available starting from glibc 2.34
|
|
|
|
|
|
|
|
|
|
This is, at least today, a very broken target: It doesn't actually build either
musl or wasi-libc even if you use -lc. It does give you musl headers, but that's
it. Those headers are not terribly useful, however, without any implementation
code. You can sort of call some math functions because they just so happen to
have implementations in compiler-rt. But that's only true for a small subset,
and I don't think users should be relying on the ABI surface of a library that
is an implementation detail of the compiler.
Clearly, a freestanding-capable libc of sorts is a useful thing as evidenced by
newlib, picolibc, etc existing. However, calling it "musl" is misleading when it
isn't actually musl-compatible, nor can it ever be because the musl API surface
is inextricably tied to the Linux kernel. In the discussion on #20690, there was
agreement that once we split up the API and ABI components in the target string,
the API component should be about compatibility, not whether you literally get a
particular implementation of it. Also, we decided that Linux musl and wasi-libc
musl shouldn't use the same API tag precisely because they're not actually
compatible.
(And besides, how would any syscall even be implemented in freestanding? Who or
what would we be calling?)
So I think we should remove this triple for now. If we decide to reintroduce
something like this, especially once #2879 gets going, we should come up with a
bespoke name for it rather than using "musl".
|
|
|
|
|
|
Adds mips64-linux-muslabin32 and x86_64-linux-muslx32 headers.
|
|
|
|
_FORTIFY_SOURCE is enabled.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
|
|
Linux 6.10 headers/syscalls
|
|
|
|
|
|
The former are soft float; the latter are hard float. We primarily care about
hard float here.
Signed-off-by: Alex Rønne Petersen <alex@alexrp.com>
|
|
This target triple was weird on multiple levels:
* The `ilp32` ABI is the soft float ABI. This is not the main ABI we want to
support on RISC-V; rather, we want `ilp32d`.
* `gnuilp32` is a bespoke tag that was introduced in Zig. The rest of the world
just uses `gnu` for RISC-V target triples.
* `gnu_ilp32` is already the name of an ILP32 ABI used on AArch64. `gnuilp32` is
too easy to confuse with this.
* We don't use this convention for `riscv64-linux-gnu`.
* Supporting all RISC-V ABIs with this convention will result in combinatorial
explosion; see #20690.
|
