While integrating the project into our Bazel workspace, we had some
problems while building protoc in an Intel MacBook.
From my testing, the issue seems to be caused by missing include path
in the toolchain configuration to the `-none` variant of the headers.
More details below.
The issue can be reproduced directly inside `bazel-zig-cc` by including
the protobuf workspace as a dependency:
+http_archive(
+ name = "com_google_protobuf",
+ sha256 = "2d9084d3dd13b86ca2e811d2331f780eb86f6d7cb02b405426e3c80dcbfabf25",
+ strip_prefix = "protobuf-3.21.1",
+ url = "https://github.com/protocolbuffers/protobuf/archive/v3.21.1.zip",
+)
+
+load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")
+
+protobuf_deps()
And then executing:
bazel build --platforms @zig_sdk//platform:darwin_amd64 @com_google_protobuf//:protoc
The command fails with the same error both in native compilation and
cross-compiling from Linux. The error:
ERROR: <output_base>/external/zlib/BUILD.bazel:37:11: Compiling compress.c failed: undeclared inclusion(s) in rule '@zlib//:zlib':
this rule is missing dependency declarations for the following files included by 'compress.c':
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/sys/cdefs.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/sys/_symbol_aliasing.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/machine/limits.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/i386/limits.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/i386/_limits.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/sys/syslimits.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/machine/types.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/i386/types.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/i386/_types.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/sys/_types/_int8_t.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/sys/_types/_uintptr_t.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/machine/_types.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/sys/_pthread/_pthread_types.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/machine/endian.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/i386/endian.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/libkern/_OSByteOrder.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/libkern/i386/_OSByteOrder.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/sys/_types/_fd_def.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/Availability.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/AvailabilityInternal.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/sys/_pthread/_pthread_attr_t.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/sys/_pthread/_pthread_cond_t.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/sys/_pthread/_pthread_condattr_t.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/sys/_pthread/_pthread_rwlock_t.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/sys/_pthread/_pthread_rwlockattr_t.h'
'<output_base>/external/zig_sdk/lib/libc/include/x86_64-macos.10-none/sys/_pthread/_pthread_t.h'
Target @com_google_protobuf//:protoc failed to build
(<output_base> replaced manually to keep the description sane)
Note that the specific rule included in the error message will vary due
to parallelism, but the error is always the same and the missing paths
always have the same prefix (up to `x86_64-macos.10-none`).
After applying the patch, we confirmed that both native and cross compilations
works as expected and can properly build protoc.
Signed-off-by: Luis Holanda <luiscmholanda@gmail.com>
As it expects Bash to be at `/bin/bash`, the current implementation
fails to execute on NixOS, given that there bash is in a non-standard
path (i.g. `/nix/store/<hash>-bash-interactive-<version>/bin/bash`).
This patch specifically changes `/bin/bash` paths to use `/usr/bin/env bash`,
which should give the correct path in every Unix system.
Signed-off-by: Luis Holanda <luiscmholanda@gmail.com>
This is very cache-unfriendly, because quite a lot of work is done
during the final linking stage. Let's see how this improves performance
of fastbuild.
Bazel has a special command line option (--compilation_mode) for specifying how
c artifacts should be compiled. Copy over the implementation without too much
thought on whether they make sense.
See https://docs.bazel.build/versions/main/user-manual.html#flag--compilation_mode.
!!! Due to a regression in zig-cc, debug symbols are available under --compilation_mode opt
```
laurynasl@laurynasl ~/bazel-zig-cc
% bazel build -c opt //test/c:which_libc 2>/dev/null && bazel-bin/test/c/which_libc && gdb -batch --ex 'info line main' bazel-bin/test/c/which_libc
glibc_2.19
Line 4 of "test/c/main.c" starts at address 0x2014f0 <main> and ends at 0x2014f1 <main+1>.
laurynasl@laurynasl ~/bazel-zig-cc
% bazel build -c dbg //test/c:which_libc 2>/dev/null && bazel-bin/test/c/which_libc && gdb -batch --ex 'info line main' bazel-bin/test/c/which_libc
glibc_2.19
Line 4 of "test/c/main.c" starts at address 0x201500 <main> and ends at 0x201504 <main+4>.
laurynasl@laurynasl ~/bazel-zig-cc
% bazel build -c fastbuild //test/c:which_libc 2>/dev/null && bazel-bin/test/c/which_libc && gdb -batch --ex 'info line main' bazel-bin/test/c/which_libc
glibc_2.19
Function "main" not defined.
```
This linker flag causes undefined symbols to be ignored, which is the
default behavior on linux but not macos. This is required when building
shared libraries to use as e.g. Python modules. This also matches what
Bazel's built-in macos cc toolchain does.
Now that the toolchain supports multiple mirrors, we can have more
robust defaults: try ziglang.org first, then dl.jakstys.lt when that one
removes the build we rely on.
This will make builds less prone to inevitable failures of my home
server.
`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
Luis Holanda
Motiejus Jakštys