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

73 lines
2.9 KiB
Python
Raw Normal View History

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(":defs.bzl", "target_structs", "zig_tool_path")
2022-04-07 13:15:34 +03:00
load("@bazel-zig-cc//toolchain:zig_toolchain.bzl", "zig_cc_toolchain_config")
DEFAULT_TOOL_PATHS = {
"ar": "ar",
"gcc": "c++", # https://github.com/bazelbuild/bazel/issues/4644
"cpp": "/usr/bin/false",
"gcov": "/usr/bin/false",
"nm": "/usr/bin/false",
"objdump": "/usr/bin/false",
"strip": "/usr/bin/false",
}.items()
def declare_cc_toolchains(os, zig_sdk_path):
2022-04-07 13:15:34 +03:00
for target_config in target_structs():
gotarget = target_config.gotarget
zigtarget = target_config.zigtarget
cxx_builtin_include_directories = []
for d in getattr(target_config, "toplevel_include", []):
cxx_builtin_include_directories.append(zig_sdk_path + "/" + d)
2022-04-07 13:15:34 +03:00
absolute_tool_paths = {}
for name, path in target_config.tool_paths.items() + DEFAULT_TOOL_PATHS:
if path[0] == "/":
absolute_tool_paths[name] = path
continue
tool_path = zig_tool_path(os).format(
zig_tool = path,
zigtarget = zigtarget,
)
2022-09-21 13:14:29 +03:00
absolute_tool_paths[name] = tool_path
2022-04-07 13:15:34 +03:00
dynamic_library_linkopts = target_config.dynamic_library_linkopts
2022-04-07 13:15:34 +03:00
copts = target_config.copts
linkopts = []
2022-04-07 13:15:34 +03:00
for s in getattr(target_config, "linker_version_scripts", []):
linkopts = ["-Wl,--version-script,%s/%s" % (zig_sdk_path, s)]
2022-04-07 13:15:34 +03:00
for incl in getattr(target_config, "compiler_extra_includes", []):
copts = copts + ["-include", zig_sdk_path + "/" + incl]
2022-04-07 13:15:34 +03:00
zig_cc_toolchain_config(
name = zigtarget + "_cc_config",
target = zigtarget,
tool_paths = absolute_tool_paths,
cxx_builtin_include_directories = cxx_builtin_include_directories,
copts = copts,
linkopts = linkopts,
dynamic_library_linkopts = dynamic_library_linkopts,
2022-04-07 13:15:34 +03:00
target_cpu = target_config.bazel_target_cpu,
target_system_name = "unknown",
target_libc = "unknown",
compiler = "clang",
abi_version = "unknown",
abi_libc_version = "unknown",
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
visibility = ["//visibility:private"],
2022-04-07 13:15:34 +03:00
)
native.cc_toolchain(
name = zigtarget + "_cc",
toolchain_identifier = zigtarget + "-toolchain",
toolchain_config = ":%s_cc_config" % zigtarget,
all_files = "@zig_sdk//:%s_all_files" % zigtarget,
2022-12-13 17:19:42 +02:00
ar_files = "@zig_sdk//:%s_ar_files" % zigtarget,
compiler_files = "@zig_sdk//:%s_compiler_files" % zigtarget,
linker_files = "@zig_sdk//:%s_linker_files" % zigtarget,
2022-04-07 13:15:34 +03:00
dwp_files = "@zig_sdk//:empty",
objcopy_files = "@zig_sdk//:empty",
strip_files = "@zig_sdk//:empty",
supports_param_files = 0,
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
visibility = ["//visibility:private"],
2022-04-07 13:15:34 +03:00
)