The documentation (e.g. `man 7 rtnetlink`) states that ifi_change "is reserved for future use and should be always set to 0xFFFFFFFF". This is no longer true, even though the text hasn't been updated.
The only allowed system libraries that we can link are libraries
that are part of the sysroot such as libc or WASI emulated
subcomponents. This is required as Wasm allows to defer symbol
resolution until load time.
For example, the following import in Zig
```zig
extern "wasi_snapshot_preview1" fn proc_exit() void;
```
would normally result in appending `-lwasi_snapshot_preview1` flag
to the linker line. However, for Wasm/WASI, the symbol is provided
at load rather than link time, therefore, the linker should not be
concerned with resolving the symbol. As a result, we should not
consider system libs by the Wasm linker.
closes#9034
These options were listed under the
"Debug Options (Zig Compiler Development)" heading. Anything in this
section should be considered unstable and can be modified at any time
at any developer's discretion.
Zig has detection for when it is accidentally being called recursively
when trying to find the native libc installation. However it was not
working, resulting in a cryptic failure, because zig tried to execute
a command which had spaces in it rather than tokenizing it.
This improves the user experience of `zig cc` for systems that Zig
does not support cross-compiling for.
Closes#8960
I want the language reference to be divorced from any particular
community. Also remove the call to action since the docs are
known to be incomplete and are not the current focus of the project.
Closes#9055
* then, in `link/Wasm.zig` map `CRTFile` to full emulated libs name
* move logic for removing any mention of WASI snapshot
`wasi_snapshot_preview1` from `Compilation.zig` into `link/Wasm.zig`
Move parsing of system libs into `main.zig` next to where we decide
if we should link libC, and, if targeting WASI, if the specified
libname equals one of the emulated components, save it on the side
and remove it from the system libs. Then, build *only* those parts
of WASI libc that were preserved in the previous step.
This also fixes building of different crt1 bits needed to support
reactors and commands.
This replicates the expected behavior when using `clang` with
upstream `wasi-libc` sysroot: linking emulated subcomponents
such as process clocks or signals requires an explicit link flag
in the compiler invocation, for example:
```
zig cc -target wasm32-wasi -lwasi-emulated-process-clocks main.c -o main.wasm
```
This commit includes emulated libc sublibs that were not included
in the compilation and caching of WASI libc that ships with Zig.
The libs include (emulated): process clocks, getpid, mman, and signal.
With this change, it is now possible to successfully cross-compile
`wasm3` engine to WASI with `zig cc`.
For the future though, it might be worth considering splitting WASI
libc into libc-proper and modularised emulated libs as it is done
in upstream, and then have them included only if the user specifically
requests emulation/parts of it.
When linking with -lfoo syntax, this indicates to Zig that the
dependency should either be provided by Zig, or it should be dynamically
provided by the system.
For windows-gnu targets, the search path was "foo.lib". Now it
additionally looks for "libfoo.dll.a".
Closes#7799
