1
Fork 0
hermetic_cc_toolchain/toolchain/private/defs.bzl

145 lines
4.8 KiB
Python
Raw Normal View History

2022-05-29 19:35:16 +03:00
_ZIG_TOOL_PATH = "tools/{zig_tool}"
# Zig supports even older glibcs than defined below, but we have tested only
# down to 2.17.
# $ zig targets | jq -r '.glibc[]' | sort -V
_GLIBCS = [
"2.17",
"2.18",
"2.19",
"2.22",
"2.23",
"2.24",
"2.25",
"2.26",
"2.27",
"2.28",
"2.29",
"2.30",
"2.31",
"2.32",
"2.33",
"2.34",
]
2022-04-15 15:20:42 +03:00
LIBCS = ["musl"] + ["gnu.{}".format(glibc) for glibc in _GLIBCS]
2022-05-29 19:35:16 +03:00
def zig_tool_path(os):
if os == "windows":
return _ZIG_TOOL_PATH + ".bat"
else:
return _ZIG_TOOL_PATH
def target_structs():
ret = []
for zigcpu, gocpu in (("x86_64", "amd64"), ("aarch64", "arm64")):
ret.append(_target_darwin(gocpu, zigcpu))
2022-05-29 19:35:17 +03:00
ret.append(_target_windows(gocpu, zigcpu))
ret.append(_target_linux_musl(gocpu, zigcpu))
for glibc in _GLIBCS:
ret.append(_target_linux_gnu(gocpu, zigcpu, glibc))
return ret
def _target_darwin(gocpu, zigcpu):
min_os = "10"
if zigcpu == "aarch64":
min_os = "11"
return struct(
gotarget = "darwin_{}".format(gocpu),
zigtarget = "{}-macos-none".format(zigcpu),
includes = [
"libunwind/include",
# TODO: Define a toolchain for each minimum OS version
Add missing include path for MacOS platforms 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>
2022-07-27 22:13:06 +03:00
"libc/include/{}-macos.{}-none".format(zigcpu, min_os),
"libc/include/any-macos.{}-any".format(min_os),
"libc/include/any-macos-any",
],
linkopts = [],
dynamic_library_linkopts = ["-Wl,-undefined=dynamic_lookup"],
copts = [],
bazel_target_cpu = "darwin",
constraint_values = [
"@platforms//os:macos",
"@platforms//cpu:{}".format(zigcpu),
],
tool_paths = {"ld": "ld64.lld"},
)
2022-05-29 19:35:17 +03:00
def _target_windows(gocpu, zigcpu):
return struct(
gotarget = "windows_{}".format(gocpu),
zigtarget = "{}-windows-gnu".format(zigcpu),
includes = [
"libunwind/include",
"libc/include/any-windows-any",
],
linkopts = [],
dynamic_library_linkopts = [],
2022-05-29 19:35:17 +03:00
copts = [],
bazel_target_cpu = "x64_windows",
constraint_values = [
"@platforms//os:windows",
"@platforms//cpu:{}".format(zigcpu),
],
tool_paths = {"ld": "ld64.lld"},
)
def _target_linux_gnu(gocpu, zigcpu, glibc_version):
glibc_suffix = "gnu.{}".format(glibc_version)
# https://github.com/ziglang/zig/issues/5882#issuecomment-888250676
# fcntl_hack is only required for glibc 2.27 or less.
fcntl_hack = glibc_version < "2.28"
return struct(
gotarget = "linux_{}_{}".format(gocpu, glibc_suffix),
zigtarget = "{}-linux-{}".format(zigcpu, glibc_suffix),
includes = [
defs: fix import paths Empirically these need to come from most specfic to least specific. The error message is as follows: In file included from test/c/main.c:1: In file included from external/zig_sdk/lib/libcxx/include/stdio.h:107: In file included from external/zig_sdk/lib/libc/include/generic-glibc/stdio.h:38: external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:139:3: error: # error ^ external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:145:1: error: unknown type name '__STD_TYPE' __STD_TYPE __DEV_T_TYPE __dev_t; /* Type of device numbers. */ Dissected `generic-glibc/bits/types.h:#error`: #if __WORDSIZE == 32 <...> # define __STD_TYPE __extension__ typedef #elif __WORDSIZE == 64 <...> # define __STD_TYPE typedef #else # error #endif So we do not have the `__WORDSIZE`. Where does that come from? Probably from a directory that has an `x86_64` in it. How does that get included? Let's start with `lib/libcxx/include/stdio.h`: 16 #include_next <stdio.h> Now previously our `c++` command line looked like this: external/zig_sdk/tools/c++ \ <...> -Iexternal/zig_sdk/lib/include \ -Iexternal/zig_sdk/lib/libcxx/include \ -Iexternal/zig_sdk/lib/libcxxabi/include \ -Iexternal/zig_sdk/lib/libunwind/include \ -Iexternal/zig_sdk/lib/libc/include/generic-glibc \ -Iexternal/zig_sdk/lib/libc/include/any-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-gnu \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86-linux-any \ -Iexternal/zig_sdk/glibc-hacks \ <...> So the next place it will find `stdio.h` is in `generic-glibc`, which already uses the `__WORDSIZE`. If we make the "next" include to be the arch-specific one instead of the generic-glibc, things start compiling again. Fix the same fo musl.
2022-09-26 10:14:08 +03:00
"libc/include/{}-linux-gnu".format(zigcpu),
"libc/include/generic-glibc",
] +
# x86_64-linux-any is x86_64-linux and x86-linux combined.
(["libc/include/x86-linux-any"] if zigcpu == "x86_64" else []) +
(["libc/include/{}-linux-any".format(zigcpu)] if zigcpu != "x86_64" else []) + [
"libc/include/any-linux-any",
defs: fix import paths Empirically these need to come from most specfic to least specific. The error message is as follows: In file included from test/c/main.c:1: In file included from external/zig_sdk/lib/libcxx/include/stdio.h:107: In file included from external/zig_sdk/lib/libc/include/generic-glibc/stdio.h:38: external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:139:3: error: # error ^ external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:145:1: error: unknown type name '__STD_TYPE' __STD_TYPE __DEV_T_TYPE __dev_t; /* Type of device numbers. */ Dissected `generic-glibc/bits/types.h:#error`: #if __WORDSIZE == 32 <...> # define __STD_TYPE __extension__ typedef #elif __WORDSIZE == 64 <...> # define __STD_TYPE typedef #else # error #endif So we do not have the `__WORDSIZE`. Where does that come from? Probably from a directory that has an `x86_64` in it. How does that get included? Let's start with `lib/libcxx/include/stdio.h`: 16 #include_next <stdio.h> Now previously our `c++` command line looked like this: external/zig_sdk/tools/c++ \ <...> -Iexternal/zig_sdk/lib/include \ -Iexternal/zig_sdk/lib/libcxx/include \ -Iexternal/zig_sdk/lib/libcxxabi/include \ -Iexternal/zig_sdk/lib/libunwind/include \ -Iexternal/zig_sdk/lib/libc/include/generic-glibc \ -Iexternal/zig_sdk/lib/libc/include/any-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-gnu \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86-linux-any \ -Iexternal/zig_sdk/glibc-hacks \ <...> So the next place it will find `stdio.h` is in `generic-glibc`, which already uses the `__WORDSIZE`. If we make the "next" include to be the arch-specific one instead of the generic-glibc, things start compiling again. Fix the same fo musl.
2022-09-26 10:14:08 +03:00
],
toplevel_include = ["glibc-hacks"] if fcntl_hack else [],
compiler_extra_includes = ["glibc-hacks/glibchack-fcntl.h"] if fcntl_hack else [],
linker_version_scripts = ["glibc-hacks/fcntl.map"] if fcntl_hack else [],
linkopts = ["-lc++", "-lc++abi"],
dynamic_library_linkopts = [],
copts = [],
bazel_target_cpu = "k8",
constraint_values = [
"@platforms//os:linux",
"@platforms//cpu:{}".format(zigcpu),
],
libc_constraint = "@zig_sdk//libc:{}".format(glibc_suffix),
tool_paths = {"ld": "ld.lld"},
)
def _target_linux_musl(gocpu, zigcpu):
return struct(
gotarget = "linux_{}_musl".format(gocpu),
zigtarget = "{}-linux-musl".format(zigcpu),
includes = [
defs: fix import paths Empirically these need to come from most specfic to least specific. The error message is as follows: In file included from test/c/main.c:1: In file included from external/zig_sdk/lib/libcxx/include/stdio.h:107: In file included from external/zig_sdk/lib/libc/include/generic-glibc/stdio.h:38: external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:139:3: error: # error ^ external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:145:1: error: unknown type name '__STD_TYPE' __STD_TYPE __DEV_T_TYPE __dev_t; /* Type of device numbers. */ Dissected `generic-glibc/bits/types.h:#error`: #if __WORDSIZE == 32 <...> # define __STD_TYPE __extension__ typedef #elif __WORDSIZE == 64 <...> # define __STD_TYPE typedef #else # error #endif So we do not have the `__WORDSIZE`. Where does that come from? Probably from a directory that has an `x86_64` in it. How does that get included? Let's start with `lib/libcxx/include/stdio.h`: 16 #include_next <stdio.h> Now previously our `c++` command line looked like this: external/zig_sdk/tools/c++ \ <...> -Iexternal/zig_sdk/lib/include \ -Iexternal/zig_sdk/lib/libcxx/include \ -Iexternal/zig_sdk/lib/libcxxabi/include \ -Iexternal/zig_sdk/lib/libunwind/include \ -Iexternal/zig_sdk/lib/libc/include/generic-glibc \ -Iexternal/zig_sdk/lib/libc/include/any-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-gnu \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86-linux-any \ -Iexternal/zig_sdk/glibc-hacks \ <...> So the next place it will find `stdio.h` is in `generic-glibc`, which already uses the `__WORDSIZE`. If we make the "next" include to be the arch-specific one instead of the generic-glibc, things start compiling again. Fix the same fo musl.
2022-09-26 10:14:08 +03:00
"libc/include/{}-linux-musl".format(zigcpu),
"libc/include/generic-musl",
] +
# x86_64-linux-any is x86_64-linux and x86-linux combined.
(["libc/include/x86-linux-any"] if zigcpu == "x86_64" else []) +
(["libc/include/{}-linux-any".format(zigcpu)] if zigcpu != "x86_64" else []) + [
"libc/include/any-linux-any",
defs: fix import paths Empirically these need to come from most specfic to least specific. The error message is as follows: In file included from test/c/main.c:1: In file included from external/zig_sdk/lib/libcxx/include/stdio.h:107: In file included from external/zig_sdk/lib/libc/include/generic-glibc/stdio.h:38: external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:139:3: error: # error ^ external/zig_sdk/lib/libc/include/generic-glibc/bits/types.h:145:1: error: unknown type name '__STD_TYPE' __STD_TYPE __DEV_T_TYPE __dev_t; /* Type of device numbers. */ Dissected `generic-glibc/bits/types.h:#error`: #if __WORDSIZE == 32 <...> # define __STD_TYPE __extension__ typedef #elif __WORDSIZE == 64 <...> # define __STD_TYPE typedef #else # error #endif So we do not have the `__WORDSIZE`. Where does that come from? Probably from a directory that has an `x86_64` in it. How does that get included? Let's start with `lib/libcxx/include/stdio.h`: 16 #include_next <stdio.h> Now previously our `c++` command line looked like this: external/zig_sdk/tools/c++ \ <...> -Iexternal/zig_sdk/lib/include \ -Iexternal/zig_sdk/lib/libcxx/include \ -Iexternal/zig_sdk/lib/libcxxabi/include \ -Iexternal/zig_sdk/lib/libunwind/include \ -Iexternal/zig_sdk/lib/libc/include/generic-glibc \ -Iexternal/zig_sdk/lib/libc/include/any-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-gnu \ -Iexternal/zig_sdk/lib/libc/include/x86_64-linux-any \ -Iexternal/zig_sdk/lib/libc/include/x86-linux-any \ -Iexternal/zig_sdk/glibc-hacks \ <...> So the next place it will find `stdio.h` is in `generic-glibc`, which already uses the `__WORDSIZE`. If we make the "next" include to be the arch-specific one instead of the generic-glibc, things start compiling again. Fix the same fo musl.
2022-09-26 10:14:08 +03:00
],
linkopts = [],
dynamic_library_linkopts = [],
copts = ["-D_LIBCPP_HAS_MUSL_LIBC", "-D_LIBCPP_HAS_THREAD_API_PTHREAD"],
bazel_target_cpu = "k8",
constraint_values = [
"@platforms//os:linux",
"@platforms//cpu:{}".format(zigcpu),
],
libc_constraint = "@zig_sdk//libc:musl",
tool_paths = {"ld": "ld.lld"},
)