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
- add rules to run tests for a specific platform
- use downloaded buildifier
- move lint to a script
- rename ci tasks
- stop running under qemu-aarch64-static as it doesn't do anything
Motiejus Jakštys
Motiejus Jakštys