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.
The user may want to build with `--sandbox_tmpfs_path=/tmp`, in which
case the Zig cache will not be shared between sandboxes, massively
slowing down the build. With this feature, the user can pass flags
like `--repo_env=BAZEL_ZIG_CC_CACHE_PREFIX=$HOME/.cache/bazel-zig-cc`
together with `--sandbox_writable_path=$HOME/.cache/bazel-zig-cc` to
put the cache somewhere else which can be shared between sandboxes.
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>
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
Motiejus Jakštys
Motiejus Jakštys