Currently, Zig uses the oldest Debian release that is still under LTS
for the default version minimum. This is now Debian 10 (Buster), with
long-term support until 2024-06-30.
Debian Buster uses Linux 4.19 and glibc 2.28.
For the default version maximum, Zig uses the newest stable Linux
version, which is currently 6.5.7.
Citations:
* https://www.debian.org/News/2019/20190706
* https://packages.debian.org/source/buster/glibc
* https://kernel.org/
Previous update commit: 1530203c80
* support 0x prefixed hex code for CLI seed arguments
* don't change the build summary; the printed CLI on build runner
failure is sufficient
* use `std.crypto.random` instead of system time for entropy
This reverts commit d7b73af8f6.
I did not look at this closely enough. This is incorrect; it should not
implicitly add rpaths for every library, and it should not disable the
nice default of each_lib_path when compiling for the native OS.
See #16062 where we are working on a follow-up improvement to this.
XXH3 is the faster alternative to XXH64 which utilizes SIMD
when hashing large chunks of memory and similar mixing to
WyHash (64x64 -> 128 mul) for smaller inputs.
Co-authored-by: Reixcon226 <87927264+Rexicon226@users.noreply.github.com>
---------
Co-authored-by: kprotty <kbutcher6200@gmail.com>
An embedded manifest file is really just XML data embedded as a RT_MANIFEST resource (ID = 24). Typically, the Windows-only 'Manifest Tool' (`mt.exe`) is used to embed manifest files, and `mt.exe` also seems to perform some transformation of the manifest data before embedding, but in testing it doesn't seem like the transformations are necessary to get the intended result.
So, to handle embedding manifest files, Zig now takes the following approach:
- Generate a .rc file with the contents `1 24 "path-to-manifest.manifest"`
- Compile that generated .rc file into a .res file
- Link the .res file into the final binary
This effectively achieves the same thing as `mt.exe` minus the validation/transformations of the XML data that it performs.
How this is used:
On the command line:
```
zig build-exe main.zig main.manifest
```
(on the command line, specifying a .manifest file when the target object format is not COFF is an error)
or in build.zig:
```
const exe = b.addExecutable(.{
.name = "manifest-test",
.root_source_file = .{ .path = "main.zig" },
.target = target,
.optimize = optimize,
.win32_manifest = .{ .path = "main.manifest" },
});
```
(in build.zig, the manifest file is ignored if the target object format is not COFF)
Note: Currently, only one manifest file can be specified per compilation. This is because the ID of the manifest resource is currently always 1. Specifying multiple manifests could be supported if a way for the user to specify an ID for each manifest is added (manifest IDs must be a u16).
Closes#17406
options
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.
