These are tripping on 32-bit x86 but are intended to prevent glibc
itself from being built with a bad configuration. Zig is only using this
file to create libc_nonshared.a, so it's not relevant.
This is the only place in all of glibc that this macro is referenced.
What is it doing? Only preventing fstatat.c from knowing the type
definition of `__time64_t`, apparently.
Fixes compilation of fstatat.c on 32-bit x86.
I could have just included the file from upstream glibc, but it was too
silly so I just inlined it. This patch could be dropped in a future
glibc update if desired. If omitted it will cause easily solvable
C compilation failures building glibc nonshared.
- `fcntl` was renamed to `fcntl64` in glibc 2.28 (see #9485)
- `res_{,n}{search,query,querydomain}` became "their own" symbols since
glibc 2.34: they were prefixed with `__` before.
This PR makes it possible to use `fcntl` with glibc 2.27 or older and
the `res_*` functions with glibc 2.33 or older.
These patches will become redundant with universal-headers and can be
dropped. But we have to do with what we have now.
This is a patch to glibc features.h which makes
_DYNAMIC_STACK_SIZE_SOURCE undefined unless the version is >= 2.34.
This feature was introduced with glibc 2.34 and without this patch, code
built against these headers but then run on an older glibc will end up
making a call to sysconf() that returns -1 for the value of SIGSTKSZ
and MINSIGSTKSZ.
The previous code incorrectly added `sub_path` twice.
Also for the compilation unit, it was passing empty string to realpath,
resulting in the error handling codepath being used.
closes#17482
When analyzing the `validate_ref_ty` ZIR instruction, an assertion would
trip if the result type was a var args function argument. The fix is the
same as e6b73be870a39f4da7a08a40da23e38b5e9613da - inline the logic of
`resolveType` and handle the case of var args.
Closes#17494
When analyzing the `as` ZIR instruction, an assertion would trip if the
result type was a var args function argument. The fix is simple: inline
a little bit of the `resolveType` logic into `analyzeAs` to make it
detect this situation - which it was already attempting to do.
Closes#16197
SPARCs have delayed branches, that is, it will unconditionally
run the next instruction following a branch.
Slightly reorder the _start code sequence to prevent it from
accidentally executing stray instructions, which may result in odd
program behavior.
This makes tmp_directory close before calling renameTmpIntoCache which fixes occurences of those AccessDenied errors that aren't synonymous with PathAlreadyExists on Windows
