I will be shutting down ~motiejus/bazel-zig-cc@lists.sr.ht within days.
Now that comms are in Slack and github issues/PRs, let's add the
archive for historical reference.
It can be opened and read through like this:
mutt -R -f mailing-list-archive.mbox
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".
Zig does not always share `libc++.a` and the glibc shims. We have observed
to be caused for 2 reasons:
- For some commands Go `chdir`s to `/tmp/`. This causes `ZIG_LIB_DIR` to be
absolute, which blows the cache key to find the right `libc++.a` (because Zig
thinks we are using a different lib dir to compile libc++). This is currently
worked around in `toolchain/defs.bzl` by overfitting to Go and returning
early from that particular invocation.
- Sometimes Bazel's sandbox messes up Zig's cache keys. If one runs without the
sandbox (`--spawn_strategy=standalone`), the cache hit rate and thus the
build time are much better.
This is actively investigated. I am adding `--spawn_strategy=standalone`
to CI to see the speedup that it provides. I will rollback it later.
'common' is not a thing in Windows; but it needs to be defined.
This makes v1.0.0-rc3 broken for Windows, and not useful (yet) for
anyone else but me. Revert the README update too.
`zig cc` emits `--gc-sections` for the linker, which is incompatbile
with what CGo thinks about linking.
This commit adds a workaround: it will add `--no-gc-sections` to the
linking step if the command is not specified (falling back to the
default behavior of gcc/clang).
Related: https://github.com/golang/go/issues/52690
