`res_search` became a proper symbol only in glibc 2.34. Until that it
was re-defined in headers, hitting the (in-)famous
https://github.com/ziglang/zig/issues/9485
glibc 2.34+:
resolv/resolv.h:int res_search (const char *, int, int, unsigned char *, int)
Old glibc:
resolv/resolv.h:#define res_search __res_search
Also, remove the toplevel includes, as they should never be included in
the first place: the headers are included explicitly when needed.
Until now we needed to maintain two versions of the zig launcher: one
for Windows and one for everything else. This was problematic for two
reasons:
1. I do not know powershell and thus keep breaking the Windows wrapper
all the time (see git history of Fabian fixing stuff that I broke).
2. This makes bazel-zig-cc dependent on the system shell, making it not
really hermetic. So the recently added
`--experimental_use_hermetic_linux_sandbox` does not work with
bazel-zig-cc, unless we bind-mount a bunch of stuff: `/usr`, `/bin`,
`/lib`, `/usr/lib:/lib`, `/usr/lib64:/lib64` and `/proc`.
Switching to a Zig-based wrapper solves both issues, and we can do this:
bazel build "$@" \
--experimental_use_hermetic_linux_sandbox \
--sandbox_add_mount_pair=/proc \
<...>
Zig itself still depends on `/proc` for `/proc/self/exe`, so we need to
keep that. I will look into reducing even that dependency separately.
Not all is nice and shiny though: this commit replaces ~80 LOC worth of
shell scripts wrappers with a singe ~300 LOC zig program, which is
arguably harder to understand. However, it is easier to change, at least
for me, because it's a single file with unit tests! Most importantly,
the gnarly code (which resolves paths and sets environment variables) is
cross-platform.
Thanks to Fabian Hahn for testing this on Windows and pointing out
errors.
Now that we have more than one contributor, it's fair be explicit about
it. I never asked for CLA and who owns the copyright has been clearly
documented in the README.
Note that this is not a policy change.
* cc: bazel supports only cpp
* wasm-ld: we do not support wasm here. Can be re-added with proper target config.
* coff: we use ld64.lld for some reason (I don't know enough about Windows to tell)
Also, now creating the tools where it makes sense to add for the target only.
While the original intention to be "xdg-friendly" was honorable, it
never worked in practice. Bazel has a tendency to remove almost all
environment variables during the build, causing only the fallback to
remain (i.e. all zig's cache to be put to /tmp/bazel-zig-cc).
If we just accept the world as is, we can get rid of half of the shell
wrappers.
On macos, dynamic libraries are generated as "libfoo.dylib".
On windows, executables end with ".exe", static libraries end with ".lib",
and dynamic libraries end with ".dll".
We already know which headers are necessary, so it's wasteful to put the
full zig_sdk to every sandbox.
This reduces the number of files in `external/zig_sdk` from 15k to 4k or
6k, depending on the action.
The slowness of bazel-zig-cc comes from setup and teardown of sandbox
directories[1]. Turning on `experimental_reuse_sandbox_directories`
speeds it up significantly.
Depending on how the tests with this go in the next few days, I will add
this recommendation to README.
This has been marked as safe to use and no longer experimental as of
Bazel master[2].
[1]: https://git.sr.ht/~motiejus/test-zigcc
[2]: https://github.com/bazelbuild/bazel/pull/16490
Just like we know the path to zig_lib_dir, we do know the path to
zig_exe. Lets use that.
This was surfaced by experimenting with
`--experimental_use_hermetic_linux_sandbox`.
`repository_ctx.path("zig")` would return the real file system path to
zig (outside of the sandbox), which is not good when the sandbox is
hermetic.
Co-developed-by: Fabian Hahn <fabian@hahn.graphics>
Cache reuse in zig is currently quite fragile (we are using a forked
version with github.com/ziglang/zig/issues/13051), so ensure that it
does not regress when zig SDK upgrades.
Previously the toolchain wrappers used to assume the zig_lib_dir is
always in "lib". However, it depends on the OS: macos-x86_64 and
linux-aarch64 have it in "lib/zig".
Update the wrapper scripts to reflect that.
Motiejus Jakštys
Motiejus Jakštys