This cache directory can be re-used by everything and everyone. There is
nothing bazel or hermetic_cc_toolchain specific there. So let's make it
clear.
Also, if there are any more zig-based toolchains on top of Bazel or
other build systems where they cannot rely on $HOME, but need an
absolute path, this feels like a reasonable choice.
From https://github.com/marler8997/zig-unofficial-releases
I also updated the "Release Process" wiki instructing how to use it.
Long live Mr. Marler!
The launcher got a facelift because of this error:
/code/zig-linux-x86_64-0.11.0-dev.2619+bd3e248c7/lib/std/fmt.zig:2013:9: error: function called at runtime cannot return value at comptime
return &buf;
^~~~~~~~~~~
referenced by:
test.launcher:parseArgs: toolchain/launcher.zig:334:31
remaining reference traces hidden; use '-freference-trace' to see all reference traces
Zig gets confused by the requirement in that test in a runtime context.
This log message has been seen in a Github Actions worker:
running <...>/c++ failed: signal: illegal instruction (core dumped)
I conclude that the launcher was compiled on a newer CPU than used on
the worker at the time.
Reported-by: mp@edgeless.systemsFixes#22
We are using only a single trivial function `paths`, which can be
bundled. Makes things like test-zigcc[1] easier: less dependencies to
worry about.
[1]: https://git.jakstys.lt/motiejus/test-zig-cc/
Sometimes the launcher fails to compile with the following error
messsage:
```
error: FileNotFound
```
We cannot reproduce this in a controlled environment, but see it
happening in the wild often enough to receive repeated questions.
Since this has been escalated to Zig Software Foundation, the most
meaningful thing we can ask our users to do is apply a workaround and
wait. Let's do just that.
Your old version of the software released under the old license can
still be used under the terms of the old license.
I have received the following statement from the past contributors
Luis Holanda, Jeremy Volkman and Fabian Hahn:
I hereby confirm that I am the copyright holder or authorized by the
copyright holder of this contribution. As such I hereby confirm that
all contributions made to bazel-zig-cc by me or on behalf of me,
hereby is licensed under the Apache 2.0 License
[http://www.apache.org/licenses/LICENSE-2.0]. I am aware that my
previous contributions will still be available under the MIT license
as well. I confirm that I am aware of the bazel-zig-cc teams intention
to release bazel-zig-cc under the Apache 2.0 License from release
[1.0] and onwards, and that the bazel-zig-cc no longer will accept
contributions made under the MIT and that any future submissions from
myself will be considered to be licensed under Apache 2.0 unless I
expressly state otherwise.
Copyright and re-licensing for Google and Uber employees has been
resolved internally.
Since not all contributors took action to re-license the code yet,
portions of bazel-zig-cc remain licensed as MIT.
I have started this project during my personal time with my personal
resources. I am now handing over all copyrights to this code to Uber
Technologies, Inc.
`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.
* 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.
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>
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
