1
hermetic_cc_toolchain/toolchain/defs.bzl

285 lines
9.3 KiB
Python
Raw Normal View History

2021-04-10 01:05:01 +03:00
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
load("@bazel_tools//tools/build_defs/repo:utils.bzl", "read_user_netrc", "use_netrc")
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
load("@bazel-zig-cc//toolchain/private:defs.bzl", "target_structs", "zig_tool_path")
# Directories that `zig c++` includes behind the scenes.
_DEFAULT_INCLUDE_DIRECTORIES = [
"libcxx/include",
"libcxxabi/include",
"libunwind/include",
]
2021-04-10 01:05:01 +03:00
_fcntl_map = """
GLIBC_2.2.5 {
fcntl;
};
"""
_fcntl_h = """
#ifdef __ASSEMBLER__
.symver fcntl64, fcntl@GLIBC_2.2.5
#else
__asm__(".symver fcntl64, fcntl@GLIBC_2.2.5");
#endif
"""
2022-01-25 11:05:35 +02:00
# Official recommended version. Should use this when we have a usable release.
URL_FORMAT_RELEASE = "https://ziglang.org/download/{version}/zig-{host_platform}-{version}.{_ext}"
2022-01-25 11:05:35 +02:00
# Caution: nightly releases are purged from ziglang.org after ~90 days. A real
# solution would be to allow the downstream project specify their own mirrors.
# This is explained in
# https://sr.ht/~motiejus/bazel-zig-cc/#alternative-download-urls and is
# awaiting my attention or your contribution.
URL_FORMAT_NIGHTLY = "https://ziglang.org/builds/zig-{host_platform}-{version}.{_ext}"
2022-01-25 11:05:35 +02:00
# Author's mirror that doesn't purge the nightlies so aggressively. I will be
# cleaning those up manually only after the artifacts are not in use for many
# months in bazel-zig-cc. dl.jakstys.lt is a small x86_64 server with an NVMe
# drive sitting in my home closet on a 1GB/s symmetric residential connection,
# which, as of writing, has been quite reliable.
URL_FORMAT_JAKSTYS = "https://dl.jakstys.lt/zig/zig-{host_platform}-{version}.{_ext}"
_VERSION = "0.10.0-dev.4166+cae76d829"
_HOST_PLATFORM_SHA256 = {
"linux-aarch64": "0137b1e7225668ea41ef359ac50865b66b016d4048d0d1f082e50906a4ddcea4",
"linux-x86_64": "071aaf393bca6142e9d002f995570b9a439bc09ebfbc4ec7c995619217e6b468",
"macos-aarch64": "959564f213bab41a40ca0b0280f82e981b0c7afc0a46bf875f8a8c2e0bd776ae",
"macos-x86_64": "563ddb8c58fde5efaa32d94756fd6095b5d229abbf3d1d7e6a9e54c3fcf69bb5",
"windows-x86_64": "aa1c95e74b703a5946a168e404ce0f57e70db43e6c1c1ba89a65fab254df29c1",
2022-05-29 19:35:16 +03:00
}
_HOST_PLATFORM_EXT = {
"linux-aarch64": "tar.xz",
"linux-x86_64": "tar.xz",
"macos-aarch64": "tar.xz",
"macos-x86_64": "tar.xz",
"windows-x86_64": "zip",
}
def toolchains(
version = _VERSION,
url_formats = [URL_FORMAT_NIGHTLY, URL_FORMAT_JAKSTYS],
2022-05-29 19:35:16 +03:00
host_platform_sha256 = _HOST_PLATFORM_SHA256,
host_platform_ext = _HOST_PLATFORM_EXT):
"""
Download zig toolchain and declare bazel toolchains.
The platforms are not registered automatically, that should be done by
the user with register_toolchains() in the WORKSPACE file. See README
for possible choices.
"""
2021-04-10 01:05:01 +03:00
zig_repository(
name = "zig_sdk",
version = version,
url_formats = url_formats,
host_platform_sha256 = host_platform_sha256,
2022-05-29 19:35:16 +03:00
host_platform_ext = host_platform_ext,
host_platform_include_root = {
"linux-aarch64": "lib/zig/",
"linux-x86_64": "lib/",
"macos-aarch64": "lib/",
"macos-x86_64": "lib/zig/",
2022-05-29 19:35:16 +03:00
"windows-x86_64": "lib/",
2021-06-16 12:44:16 +03:00
},
2021-04-10 01:05:01 +03:00
)
_ZIG_TOOLS = [
"c++",
"cc",
"ar",
"ld.lld", # ELF
"ld64.lld", # Mach-O
"lld-link", # COFF
"wasm-ld", # WebAssembly
]
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
# TODO: ZIG_LIB_DIR equivalent in powershell?
_ZIG_TOOL_WRAPPER_WINDOWS_CACHE_KNOWN = """@echo off
set ZIG_LOCAL_CACHE_DIR={cache_prefix}\\bazel-zig-cc
set ZIG_GLOBAL_CACHE_DIR=%ZIG_LOCAL_CACHE_DIR%
"{zig}" "{zig_tool}" %*
"""
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
# TODO: ZIG_LIB_DIR equivalent in powershell?
_ZIG_TOOL_WRAPPER_WINDOWS_CACHE_GUESS = """@echo off
if exist "%TMP%\\*" goto :usertmp
set ZIG_LOCAL_CACHE_DIR=C:\\Temp\\bazel-zig-cc
goto zig
:usertmp
set ZIG_LOCAL_CACHE_DIR=%TMP%\\bazel-zig-cc
:zig
set ZIG_GLOBAL_CACHE_DIR=%ZIG_LOCAL_CACHE_DIR%
"{zig}" "{zig_tool}" %*
"""
_ZIG_TOOL_WRAPPER_CACHE_KNOWN = """#!/bin/sh
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
set -e
if [ -d external/zig_sdk/lib ]; then
export ZIG_LIB_DIR=external/zig_sdk/lib
else
export ZIG_LIB_DIR="$(dirname "$0")/../lib"
fi
2022-08-29 14:44:38 +03:00
export ZIG_LOCAL_CACHE_DIR="{cache_prefix}/bazel-zig-cc"
export ZIG_GLOBAL_CACHE_DIR="{cache_prefix}/bazel-zig-cc"
exec "{zig}" "{zig_tool}" "$@"
"""
2021-08-05 09:47:34 +03:00
_ZIG_TOOL_WRAPPER_CACHE_GUESS = """#!/bin/sh
set -e
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
if [ -d external/zig_sdk/lib ]; then
export ZIG_LIB_DIR=external/zig_sdk/lib
else
export ZIG_LIB_DIR="$(dirname "$0")/../lib"
fi
if [ -n "$TMPDIR" ]; then
_cache_prefix=$TMPDIR
elif [ -n "$HOME" ]; then
if [ "$(uname)" = Darwin ]; then
_cache_prefix="$HOME/Library/Caches"
else
_cache_prefix="$HOME/.cache"
fi
2021-06-10 09:10:48 +03:00
else
_cache_prefix=/tmp
2021-06-10 09:10:48 +03:00
fi
2021-08-05 09:47:34 +03:00
export ZIG_LOCAL_CACHE_DIR="$_cache_prefix/bazel-zig-cc"
2021-06-10 09:10:48 +03:00
export ZIG_GLOBAL_CACHE_DIR=$ZIG_LOCAL_CACHE_DIR
exec "{zig}" "{zig_tool}" "$@"
"""
def _zig_tool_wrapper(zig_tool, zig, is_windows, cache_prefix):
kwargs = dict(
zig = str(zig).replace("/", "\\") + ".exe" if is_windows else zig,
zig_tool = zig_tool,
cache_prefix = cache_prefix,
)
2022-05-29 19:35:16 +03:00
if is_windows:
if cache_prefix:
return _ZIG_TOOL_WRAPPER_WINDOWS_CACHE_KNOWN.format(**kwargs)
else:
return _ZIG_TOOL_WRAPPER_WINDOWS_CACHE_GUESS.format(**kwargs)
elif cache_prefix:
return _ZIG_TOOL_WRAPPER_CACHE_KNOWN.format(**kwargs)
else:
return _ZIG_TOOL_WRAPPER_CACHE_GUESS.format(**kwargs)
def _quote(s):
return "'" + s.replace("'", "'\\''") + "'"
2021-04-10 01:05:01 +03:00
def _zig_repository_impl(repository_ctx):
arch = repository_ctx.os.arch
if arch == "amd64":
arch = "x86_64"
os = repository_ctx.os.name.lower()
if os.startswith("mac os"):
os = "macos"
2022-05-29 19:35:16 +03:00
if os.startswith("windows"):
os = "windows"
host_platform = "{}-{}".format(os, arch)
2021-04-10 01:05:01 +03:00
zig_include_root = repository_ctx.attr.host_platform_include_root[host_platform]
zig_sha256 = repository_ctx.attr.host_platform_sha256[host_platform]
2022-05-29 19:35:16 +03:00
zig_ext = repository_ctx.attr.host_platform_ext[host_platform]
2021-04-10 01:05:01 +03:00
format_vars = {
"_ext": zig_ext,
2021-06-16 12:44:16 +03:00
"version": repository_ctx.attr.version,
"host_platform": host_platform,
2021-04-10 01:05:01 +03:00
}
2022-03-18 06:30:42 +02:00
# Fetch Label dependencies before doing download/extract.
# The Bazel docs are not very clear about this behavior but see:
# https://bazel.build/extending/repo#when_is_the_implementation_function_executed
# and a related rules_go PR:
# https://github.com/bazelbuild/bazel-gazelle/pull/1206
for dest, src in {
"platform/BUILD": "//toolchain/platform:BUILD",
"toolchain/BUILD": "//toolchain/toolchain:BUILD",
"libc/BUILD": "//toolchain/libc:BUILD",
"libc_aware/platform/BUILD": "//toolchain/libc_aware/platform:BUILD",
"libc_aware/toolchain/BUILD": "//toolchain/libc_aware/toolchain:BUILD",
}.items():
repository_ctx.symlink(Label(src), dest)
for dest, src in {
"BUILD": "//toolchain:BUILD.sdk.bazel",
2022-09-21 13:14:29 +03:00
# "private/BUILD": "//toolchain/private:BUILD.sdk.bazel",
}.items():
repository_ctx.template(
dest,
Label(src),
executable = False,
substitutions = {
"{zig_sdk_path}": _quote("external/zig_sdk"),
"{os}": _quote(os),
"{zig_include_root}": _quote(zig_include_root),
},
)
2022-03-18 07:04:49 +02:00
urls = [uf.format(**format_vars) for uf in repository_ctx.attr.url_formats]
2021-04-10 01:05:01 +03:00
repository_ctx.download_and_extract(
auth = use_netrc(read_user_netrc(repository_ctx), urls, {}),
2022-03-18 07:04:49 +02:00
url = urls,
2021-04-10 01:05:01 +03:00
stripPrefix = "zig-{host_platform}-{version}/".format(**format_vars),
sha256 = zig_sha256,
2021-04-10 01:05:01 +03:00
)
for zig_tool in _ZIG_TOOLS:
zig_tool_wrapper = _zig_tool_wrapper(
zig_tool,
str(repository_ctx.path("zig")),
os == "windows",
repository_ctx.os.environ.get("BAZEL_ZIG_CC_CACHE_PREFIX", ""),
)
2022-05-29 19:35:16 +03:00
repository_ctx.file(
zig_tool_path(os).format(zig_tool = zig_tool),
zig_tool_wrapper,
2021-04-10 01:05:01 +03:00
)
repository_ctx.file(
"glibc-hacks/fcntl.map",
content = _fcntl_map,
)
repository_ctx.file(
"glibc-hacks/glibchack-fcntl.h",
content = _fcntl_h,
)
2021-04-10 01:05:01 +03:00
zig_repository = repository_rule(
attrs = {
"version": attr.string(),
2021-04-10 02:58:05 +03:00
"host_platform_sha256": attr.string_dict(),
"url_formats": attr.string_list(allow_empty = False),
"host_platform_include_root": attr.string_dict(),
2022-05-29 19:35:16 +03:00
"host_platform_ext": attr.string_dict(),
2021-04-10 01:05:01 +03:00
},
environ = ["BAZEL_ZIG_CC_CACHE_PREFIX"],
2021-04-10 01:05:01 +03:00
implementation = _zig_repository_impl,
)
def filegroup(name, **kwargs):
native.filegroup(name = name, **kwargs)
return ":" + name
2022-05-29 19:35:16 +03:00
def declare_files(os, zig_include_root):
2022-09-21 13:14:29 +03:00
filegroup(name = "all", srcs = native.glob(["**"]))
2021-06-16 12:44:16 +03:00
filegroup(name = "empty")
2022-05-29 19:35:16 +03:00
if os == "windows":
native.exports_files(["zig.exe"], visibility = ["//visibility:public"])
native.alias(name = "zig", actual = ":zig.exe")
else:
native.exports_files(["zig"], visibility = ["//visibility:public"])
2021-06-16 12:44:16 +03:00
filegroup(name = "lib/std", srcs = native.glob(["lib/std/**"]))
2021-04-10 01:05:01 +03:00
lazy_filegroups = {}
for target_config in target_structs():
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
for d in _DEFAULT_INCLUDE_DIRECTORIES + target_config.includes:
d = zig_include_root + d
if d not in lazy_filegroups:
lazy_filegroups[d] = filegroup(name = d, srcs = native.glob([d + "/**"]))