{"id":13611835,"url":"https://github.com/uber/hermetic_cc_toolchain","last_synced_at":"2026-01-25T07:04:22.720Z","repository":{"id":137361761,"uuid":"592487143","full_name":"uber/hermetic_cc_toolchain","owner":"uber","description":"Bazel C/C++ toolchain for cross-compiling C/C++ programs","archived":false,"fork":false,"pushed_at":"2026-01-06T15:52:04.000Z","size":861,"stargazers_count":378,"open_issues_count":38,"forks_count":75,"subscribers_count":8,"default_branch":"main","last_synced_at":"2026-01-22T06:02:50.084Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Starlark","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/uber.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2023-01-23T20:44:38.000Z","updated_at":"2026-01-12T17:48:20.000Z","dependencies_parsed_at":"2023-12-18T22:59:37.340Z","dependency_job_id":"1089dbb4-84ff-4ea1-9add-57823efcd232","html_url":"https://github.com/uber/hermetic_cc_toolchain","commit_stats":null,"previous_names":["uber/bazel-zig-cc"],"tags_count":48,"template":false,"template_full_name":null,"purl":"pkg:github/uber/hermetic_cc_toolchain","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uber%2Fhermetic_cc_toolchain","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uber%2Fhermetic_cc_toolchain/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uber%2Fhermetic_cc_toolchain/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uber%2Fhermetic_cc_toolchain/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/uber","download_url":"https://codeload.github.com/uber/hermetic_cc_toolchain/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/uber%2Fhermetic_cc_toolchain/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28747308,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-25T05:12:38.112Z","status":"ssl_error","status_checked_at":"2026-01-25T05:04:50.338Z","response_time":113,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-01T19:02:12.545Z","updated_at":"2026-01-25T07:04:22.714Z","avatar_url":"https://github.com/uber.png","language":"Starlark","readme":"[![ci](https://github.com/uber/hermetic_cc_toolchain/actions/workflows/ci.yaml/badge.svg)](https://github.com/uber/hermetic_cc_toolchain/actions/workflows/ci.yaml)\n\n# Hermetic CC toolchain\n\nThis is a C/C++ toolchain that can (cross-)compile C/C++ programs on top of\n`zig cc`. It contains clang-17, musl, glibc 2.17-2.38, all in a ~40MB package.\nRead\n[here](https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html)\nabout zig-cc; the rest of the README will present how to use this toolchain\nfrom Bazel.\n\nConfiguring toolchains in Bazel is complex and fraught with peril. We, the team\nbehind `hermetic_cc_toolchain`, are still confused on how this all works, and\noften wonder why it works at all. That aside, we made our best effort to make\n`hermetic_cc_toolchain` usable for your C/C++/CGo projects, with as many\nguardrails can be installed.\n\nWhile copy-pasting the code in your project, attempt to read and understand the\ntext surrounding the code snippets. This will save you hours of head\nscratching.\n\n## Project Origin\n\nThis repository is cloned from and is based on Adam Bouhenguel's\n[bazel-zig-cc][ajbouh], and was later developed at\n`sr.ht/~motiejus/bazel-zig-cc`. After a while this repository was moved to [the\nUber GitHub repository](https://github.com/uber) and renamed to\n`hermetic_cc_toolchain`.\n\n\u003e **Our special thanks to Adam for coming up with the idea - and creating the\n\u003e original version – of `bazel-zig-cc` and publishing it. His idea and work\n\u003e helped make the concept of using Zig with Bazel a reality; now we all can\n\u003e benefit from it.**\n\n## Usage\n\n### WORKSPACE\n\nAdd this to your `WORKSPACE`:\n\n```starlark\nload(\"@bazel_tools//tools/build_defs/repo:http.bzl\", \"http_archive\")\n\nHERMETIC_CC_TOOLCHAIN_VERSION = \"v4.1.0\"\n\nhttp_archive(\n    name = \"hermetic_cc_toolchain\",\n    sha256 = \"65b9f964ffc733bbe8559ff5497a887bbd384fee1d7592f355633d655f0dff4a\",\n    urls = [\n        \"https://mirror.bazel.build/github.com/uber/hermetic_cc_toolchain/releases/download/{0}/hermetic_cc_toolchain-{0}.tar.gz\".format(HERMETIC_CC_TOOLCHAIN_VERSION),\n        \"https://github.com/uber/hermetic_cc_toolchain/releases/download/{0}/hermetic_cc_toolchain-{0}.tar.gz\".format(HERMETIC_CC_TOOLCHAIN_VERSION),\n    ],\n)\n\nload(\"@hermetic_cc_toolchain//toolchain:defs.bzl\", zig_toolchains = \"toolchains\")\n\n# Plain zig_toolchains() will pick reasonable defaults. See\n# toolchain/defs.bzl:toolchains on how to change the Zig SDK version and\n# download URL.\nzig_toolchains()\n```\n\n### MODULE.bazel\n\nAdd this to your `MODULE.bazel`:\n\n```starlark\nbazel_dep(name = \"hermetic_cc_toolchain\", version = \"3.1.0\")\n\ntoolchains = use_extension(\"@hermetic_cc_toolchain//toolchain:ext.bzl\", \"toolchains\")\nuse_repo(toolchains, \"zig_sdk\")\n\nregister_toolchains(\n    \"@zig_sdk//toolchain/...\",\n    \"@zig_sdk//libc_aware/toolchain/...\",\n```\n\n### Configuration file\n\nAnd this to `.bazelrc` on a Unix-y systems:\n\n```\ncommon --enable_platform_specific_config\nbuild:linux --sandbox_add_mount_pair=/tmp\nbuild:macos --sandbox_add_mount_pair=/var/tmp\nbuild:windows --sandbox_add_mount_pair=C:\\Temp\n```\n\nThe directories can be narrowed down to `/tmp/zig-cache` (Linux),\n`/var/tmp/zig-cache` (MacOS) and `C:\\Temp\\zig-cache` respectively\nif it can be ensured they will be created before the invocation of `bazel\nbuild`. See [#83][pr-83] for more context. If a different place is preferred\nfor zig cache, set:\n\n```\nbuild --repo_env=HERMETIC_CC_TOOLCHAIN_CACHE_PREFIX=/path/to/cache\nbuild --sandbox_add_mount_pair=/path/to/cache\n```\n\nThe snippets above will download the zig toolchain and make the bazel\ntoolchains available for registration and usage. If nothing else is done, this\nwill work for some minimal use cases. The `.bazelrc` snippet instructs Bazel to\nuse the registered \"new kinds of toolchains\". The next steps depend on how one\nwants to use `hermetic_cc_toolchain`. The descriptions below is a gentle\nintroduction to C++ toolchains from \"user's perspective\" too.\n\nSee [examples][examples] for some other recommended `.bazelrc` flags, as well\nas how to use `hermetic_cc_toolchain` with bzlmod.\n\n### Repositories\n\n`hermetic_cc_toolchain` creates few repositories to work with:\n- `@zig_sdk` - platform, constraint and toolchain definitions for supported platforms\n- `@zig_config` - internal config targets for HOST platform (not visible to main repository)\n- `@zig_config-{os}-{arch}` - internal config targets for supported platforms when explicitly provided to [toolchains()](toolchain/defs.bzl#62) macro (not visible to main repository)\n\nBy default `hermetic_cc_toolchain` creates toolchains just for the HOST execution\nplatform. To create toolchains for other execution platforms than HOST, those need\nto be explicitly specified within [toolchains()](toolchain/defs.bzl#62) macro call.\nThe dictionary argument of [exec_platforms](toolchain/defs.bzl#L67), specifies additional execution platforms and has to conform Bazel's\n[attr.string_dict()](https://bazel.build/rules/lib/toplevel/attr#string_dict), e.g.:\n\n```starlark\n_EXEC_PLATFORMS = {\n    \"linux\": [\"arm64\"],\n    \"macos\": [\"amd64\", \"arm64\"],\n    \"windows\": [\"amd64\"],\n}\n```\n\n#### WORKSPACE\n\nIf toolchains for other than HOST execution platforms are needed, pass them to `zig_toolchains()`:\n\n```\nload(\"@hermetic_cc_toolchain//toolchain:defs.bzl\", zig_toolchains = \"toolchains\")\n\n_MACOS_EXEC_PLATFORMS = {\n    \"macos\": [\"amd64\", \"arm64\"],\n}\n\nzig_toolchains(\n  exec_platforms = _MACOS_EXEC_PLATFORMS\n)\n```\n\n#### MODULE.bazel\n\n[toolchains](toolchain/ext.bzl#40) module extension provides [exec_platform](toolchain/ext.bzl#4)\ntag class, which allows to specify additional execution platforms.\nTo add toolchains for `windows-amd64` execution platform (additionally to HOST execution\nplatform), call `toolchains.exec_platform()`:\n\n```starlark\ntoolchains = use_extension(\"//toolchain:ext.bzl\", \"toolchains\")\ntoolchains.exec_platform(\n    os = \"windows\",\n    arch = \"amd64\",\n)\nuse_repo(toolchains, \"zig_sdk\")\n```\n\n### Toolchains\n\nAll toolchain definitions for the HOST execution platform are defined in:\n\n- `@zig_sdk//toolchain/...`\n  - unaware of `libc` constraint (`\"@zig_sdk//libc:variant\"`)\n- `@zig_sdk//libc_aware/toolchain/...`\n  - `libc` version aware e.g. `@zig_sdk//libc_aware/toolchain:linux_arm64_gnu.2.31`\n\nIn case of additional execution platforms, toolchains are placed with the same rule\nas for the HOST but with an additional platform _subpackage_ of `\"{os}-{arch}\"` i.e.:\n\n```starlark\n@zig_sdk//toolchain/{os}-{arch}/...\n@zig_sdk//libc_aware/toolchain/{os}-{arch}/...\n```\n\nHaving a `x86_64-linux-musl` toolchain for `@zig_sdk//platform:windows_amd64` execution platform will have full label of:\n\n```\n@zig_sdk//toolchain/windows-amd64:x86_64-linux-musl\n                    ~~~~~~~~~~~~~\n                    ^\n                    os = `windows`, arch = `x86_64`\n```\n\n### Use case: manually build a single target with a specific zig cc toolchain\n\nThis option is least disruptive to the workflow compared to no hermetic C++\ntoolchain, and works best when trying out or getting started with\n`hermetic_cc_toolchain` for a subset of targets.\n\nTo request Bazel to use a specific toolchain (compatible with the specified\nplatform) for build/tests/whatever on linux-amd64-musl, do:\n\n```\nbazel build \\\n    --platforms @zig_sdk//platform:linux_arm64 \\\n    --extra_toolchains @zig_sdk//toolchain:linux_arm64_musl \\\n    //test/go:go\n```\n\nThere are a few things going on here, let's try to dissect them.\n\n#### Option `--platforms @zig_sdk//platform:linux_arm64`\n\nSpecifies that the our target platform is `linux_arm64`, which resolves into:\n\n```\n$ bazel query --output=build @zig_sdk//platform:linux_arm64\nplatform(\n  name = \"linux_arm64\",\n  generator_name = \"linux_arm64\",\n  generator_function = \"declare_platforms\",\n  generator_location = \"platform/BUILD:7:18\",\n  constraint_values = [\"@platforms//os:linux\", \"@platforms//cpu:aarch64\"],\n)\n```\n\n`constraint_values` instructs Bazel to be looking for a **toolchain** that is\ncompatible with (in Bazelspeak, `target_compatible_with`) **all of the**\n`[\"@platforms//os:linux\", \"@platforms//cpu:aarch64\"]`.\n\n#### Option `--extra_toolchains=@zig_sdk//toolchain:linux_arm64_musl`\n\nInspect first (`@platforms//cpu:aarch64` is an alias to `@platforms//cpu:arm64`):\n\n```\n$ bazel query --output=build @zig_sdk//toolchain:linux_arm64_musl\ntoolchain(\n  name = \"linux_arm64_musl\",\n  generator_name = \"linux_arm64_musl\",\n  generator_function = \"declare_toolchains\",\n  generator_location = \"toolchains~zig_sdk/toolchain/BUILD:7:19\",\n  toolchain_type = \"@bazel_tools//tools/cpp:toolchain_type\",\n  exec_compatible_with = [\"@@_main~toolchains~zig_config//:exec_os\", \"@@_main~toolchains~zig_config//:exec_cpu\"],\n  target_compatible_with = [\"@platforms//os:linux\", \"@platforms//cpu:aarch64\", \"@zig_sdk//libc:unconstrained\"],\n  toolchain = \"@@_main~toolchains~zig_config//:aarch64-linux-musl_cc\",\n)\n```\n\nToolchain is compatible with an execution platform who satisfies\n`constraint_value`s of:\n- `@zig_config//:exec_os`\n- `@zig_config//:exec_cpu`\n\nBoth are aliases to actual `os` and `cpu` of HOST platform (here `@platforms//os:linux`\nand `@platforms//cpu:x86_64` respectively).\n\nFor a platform to pick up the right toolchain, the platform's\n`constraint_values` must be a subset[^1] of the toolchain's\n`target_compatible_with`. Since the platform is a subset (therefore,\ntoolchain's `@zig_sdk//libc:unconstrained` does not matter), this toolchain is\nselected for this platform. As a result, `--platforms\n@zig_sdk//platform:linux_amd64` causes Bazel to select a toolchain\n`@zig_sdk//platform:linux_arm64_musl` (because it satisfies all constraints),\nwhich will compile and link the C/C++ code with musl.\n\n`@zig_sdk//libc:unconstrained` will become important later.\n\n#### Same as above, less typing (with `--config`)\n\nSpecifying the platform and toolchain for every target may become burdensome,\nso they can be put used via `--config`. For example, append this to `.bazelrc`:\n\n```\nbuild:linux_arm64 --platforms @zig_sdk//platform:linux_arm64\nbuild:linux_arm64 --extra_toolchains @zig_sdk//toolchain:linux_arm64_musl\n```\n\nAnd then building to linux-arm64-musl boils down to:\n\n```\nbazel build --config=linux_arm64_musl //test/go:go\n```\n\n### Use case: always compile with zig cc\n\nInstead of adding the toolchains to `.bazelrc`, they can be added\nunconditionally.\n\n#### MODULE.bazel\n\n```\nregister_toolchains(\n    # execution HOST platform\n    \"@zig_sdk//toolchain:aarch64-linux-musl\",\n    \"@zig_sdk//libc_aware/toolchain:linux_arm64_gnu.2.31\",\n\n    # toolchains for libc-aware platforms, will be used for amd64 / arm64\n    \"@zig_sdk//libc_aware/toolchain:linux_amd64_gnu.2.28\",\n    \"@zig_sdk//libc_aware/toolchain:linux_arm64_gnu.2.28\",\n\n    # toolchains for darwin, will be used for amd64 / arm64\n    \"@zig_sdk//toolchain:darwin_amd64\",\n    \"@zig_sdk//toolchain:darwin_arm64\",\n\n    # wasm/wasi toolchains\n    \"@zig_sdk//toolchain:wasip1_wasm\",\n)\n```\n\n#### WORKSPACE\n\nAppend this to `WORKSPACE` after `zig_toolchains()`:\n\n```starlark\nload(\"@hermetic_cc_toolchain//toolchain:defs.bzl\", zig_toolchains = \"toolchains\")\n\nzig_toolchains()\n\nregister_toolchains(\n    \"@zig_sdk//toolchain:linux_amd64_gnu.2.28\",\n    \"@zig_sdk//toolchain:linux_arm64_gnu.2.28\",\n    \"@zig_sdk//toolchain:darwin_amd64\",\n    \"@zig_sdk//toolchain:darwin_arm64\",\n    \"@zig_sdk//toolchain:windows_amd64\",\n    \"@zig_sdk//toolchain:windows_arm64\",\n    \"@zig_sdk//toolchain:wasip1_wasm\",\n)\n```\n\n#### All toolchains at once\n\nTo register all available toolchains one can simply call:\n\n```starlark\nregister_toolchains(\"@zig_sdk//...\")\n```\n\n#### No local toolchains\n\nAppend this to `.bazelrc`:\n\n```\nbuild --action_env BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1\n```\n\nFrom Bazel's perspective, this is almost equivalent to always specifying\n`--extra_toolchains` on every `bazel \u003c...\u003e` command-line invocation. It also\nmeans there is no way to disable the toolchain with the command line. This is\nuseful if you find `hermetic_cc_toolchain` useful enough to compile for all of\nyour targets and tools.\n\nWith `BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1` Bazel stops detecting the default\nhost toolchain. Configuring toolchains is complicated enough, and the\nauto-detection (read: fallback to non-hermetic toolchain) is a footgun best\navoided. This option is not documented in bazel, so may break. If you intend to\nuse the hermetic toolchain exclusively, it won't hurt.\n\n### Use case: zig-cc for targets for multiple libc variants\n\nWhen some targets need to be build with different libcs (either different\nversions of glibc or musl), use a linux toolchain from\n`@zig_sdk//libc_aware/toolchains:\u003c...\u003e`. The toolchain will only be selected\nwhen building for a specific libc. For example, in `WORKSPACE`:\n\n```starlark\nregister_toolchains(\n    \"@zig_sdk//libc_aware/toolchain:linux_amd64_gnu.2.19\",\n    \"@zig_sdk//libc_aware/toolchain:linux_arm64_gnu.2.28\",\n    \"@zig_sdk//libc_aware/toolchain:x86_64-linux-musl\",\n)\n```\n\nWhat does `@zig_sdk//libc_aware/toolchain:linux_amd64_gnu.2.19` mean?\n\n```\n$ bazel query --output=build @zig_sdk//libc_aware/toolchain:linux_amd64_gnu.2.19 | grep target\n  target_compatible_with = [\"@platforms//os:linux\", \"@platforms//cpu:x86_64\", \"@zig_sdk//libc:gnu.2.19\"],\n```\n\nTo see how this relates to the platform:\n\n```\n$ bazel query --output=build @zig_sdk//libc_aware/platform:linux_amd64_gnu.2.19 | grep constraint\n  constraint_values = [\"@platforms//os:linux\", \"@platforms//cpu:x86_64\", \"@zig_sdk//libc:gnu.2.19\"],\n```\n\nIn this case, the platform's `constraint_values` and toolchain's\n`target_compatible_with` are identical, causing Bazel to select the right\ntoolchain for the requested platform. With these toolchains registered, one can\nbuild a project for a specific libc-aware platform; it will select the\nappropriate toolchain:\n\n```\n$ bazel run --platforms @zig_sdk//libc_aware/platform:linux_amd64_gnu.2.28 //test/c:which_libc_linux_amd64_gnu.2.28\nlinux glibc_2.28\n$ bazel run --platforms @zig_sdk//libc_aware/platform:linux_amd64_musl //test/c:which_libc_linux_amd64_musl\nlinux non-glibc\n$ bazel run --run_under=file --platforms @zig_sdk//libc_aware/platform:linux_arm64_gnu.2.28 //test/c:which_libc\nwhich_libc: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 2.0.0, stripped\n```\n\nTo list libc aware toolchains and platforms:\n\n```\n$ bazel query @zig_sdk//libc_aware/toolchain/...\n$ bazel query @zig_sdk//libc_aware/platform/...\n ```\n\nLibc-aware toolchains are especially useful when relying on\n[transitions][transitions], as transitioning `extra_platforms` will cause the\nhost tools to be rebuilt with the specific libc version, which takes time; also\nthe build host may not be able to run them if, say, target glibc version is\nnewer than on the host. Some tests in this repository (under `test/`) are using\ntransitions; you may check out how it's done.\n\nThe `@zig_sdk//libc:variant` constraint is necessary to select a matching\ntoolchain. Remember: the toolchain's `target_compatible_with` must be\nequivalent or a superset of the platform's `constraint_values`. This is why\nboth libc-aware platforms and libc-aware toolchains reside in their own\nnamespace; if we try to mix non-libc-aware to libc-aware, confusion ensues.\n\nTo use the libc constraints in the project's platform definitions, add a\n`@zig_sdk//libc:variant` constraint to them. See the list of available values:\n\n```\n$ bazel query \"attr(constraint_setting, @zig_sdk//libc:variant, @zig_sdk//...)\"\n```\n\n`@zig_sdk//libc:unconstrained` is a special value that indicates that no value\nfor the constraint is specified. The non libc aware linux toolchains are only\ncompatible with this value to prevent accidental silent fallthrough to them.\nThis is a guardrail.\n\n## Note: Naming\n\nBoth Go and Bazel naming schemes are accepted. For convenience with\nGo, the following Go-style toolchain aliases are created:\n\n|Bazel (zig) name | Go name  |\n|---------------- | -------- |\n|`x86_64`         | `amd64`  |\n|`aarch64`        | `arm64`  |\n|`wasm32`         | `wasm`   |\n|`macos`          | `darwin` |\n|`wasi`           | `wasip1` |\n\nFor example, the toolchain `linux_amd64_gnu.2.28` is aliased to\n`x86_64-linux-gnu.2.28`. To find out which toolchains can be registered or\nused, run:\n\n```\n$ bazel query @zig_sdk//toolchain/...\n```\n\n\u003e **For execution platform other than HOST toolchains subpackage of\n\u003e `@zig_sdk` repository uses only `go` names:**\n\n```\n$ bazel query @zig_sdk//toolchain/linux-arm64/...\n                                  ~~~~~~~~~~~\n                                  execution platform os = linux, arch = arm64\n```\n\n## Incompatibilities with clang and gcc\n\n`zig cc` is *almost* a drop-in replacement for clang/gcc. This section lists\nsome of the discovered differences and ways to live with them.\n\n### UBSAN and \"SIGILL: Illegal Instruction\"\n\n`zig cc` differs from \"mainstream\" compilers by [enabling UBSAN by\ndefault][ubsan1]. Which means your program may compile successfully and crash\nwith:\n\n```\nSIGILL: illegal instruction\n```\n\nThis flag encourages program authors to fix the undefined behavior. There are\n[many ways][ubsan2] to find the undefined behavior.\n\n## Known Issues In `hermetic_cc_toolchain`\n\nThese are the things you may stumble into when using `hermetic_cc_toolchain`.\nWe are unlikely to implement them any time soon, but patches implementing those\nwill be accepted.\n\n### Zig cache location\n\nCurrently zig cache is stored in `/var/tmp/zig-cache`, so `bazel clean\n--expunge` will not clear the zig cache. Zig's cache should be stored somewhere\nin the project's path. It is not clear how to do it.\n\nSee [#83][pr-83] for more context.\n\n### OSX: sysroot\n\nFor non-trivial programs (and for all darwin/arm64 cgo programs) MacOS SDK may\nbe necessary. Read [Jakub's comment][sysroot] about it. Support for OSX sysroot\nis currently not implemented, but patches implementing it will be accepted, as\nlong as the OSX sysroot must come through an `http_archive`.\n\nIn essence, OSX target support is not well tested with `hermetic_cc_toolchain`.\nAlso see [#10][pr-10].\n\n### Bazel 6 or earlier\n\nAdd to `.bazelrc`:\n\n```\nbuild --incompatible_enable_cc_toolchain_resolution\n```\n\n## Host Environments\n\nThis repository is used on the following (host) platforms:\n\n- `linux_amd64`, a.k.a. `x86_64`.\n- `linux_arm64`, a.k.a. `AArch64`.\n- `darwin_amd64`, the 64-bit post-PowerPC models.\n- `darwin_arm64`, the M1.\n- `windows_amd64`, a.k.a. `x64`.\n\nThe tests are running (CId) on linux-amd64.\n\n### Transient docker environment\n\nA standalone Docker environment to play with `hermetic_cc_toolchain`:\n\n```\n$ docker run -e CC=/usr/bin/false -ti --rm -v \"$PWD:/x\" -w /x debian:bookworm-slim\n# apt update \u0026\u0026 apt install --no-install-recommends -y shellcheck ca-certificates python3 git\n# git config --global --add safe.directory /x\n# tools/bazel test //...\n# ./ci/lint\n# ./ci/release\n# ./ci/zig-wrapper\n```\n## Communication\n\nWe maintain two channels for comms:\n- Github issues and pull requests.\n- Slack: `#zig` in bazelbuild.slack.com.\n\n### Previous Commuications\n\nPrevious communications were done in a mailing list; the past archive can be\naccessed like this:\n\n    git checkout v2.0.0-rc2 mailing-list-archive.mbox\n    mutt -R -f mailing-list-archive.mbox\n\n## Maintainers\n\n- [@FabianHahn](https://github.com/FabianHahn/)\n- [@jvolkman](https://github.com/jvolkman)\n- [@laurynaslubys](https://github.com/laurynaslubys)\n- [@linzhp](https://github.com/linzhp)\n- [@motiejus](https://github.com/motiejus)\n- [@sywhang](https://github.com/sywhang)\n\nGuidelines for maintainers[^2]:\n\n* Communicate intent precisely.\n* Edge cases matter.\n* Favor reading code over writing code.\n* Only one obvious way to do things.\n* Runtime crashes are better than bugs.\n* Compile errors are better than runtime crashes.\n* Incremental improvements.\n* Avoid local maximums.\n* Reduce the amount one must remember.\n* Focus on code rather than style.\n* Resource allocation may fail; resource deallocation must succeed.\n* Memory is a resource.\n* Together we serve the users.\n\nOn a more practical note:\n\n- Maintainers can merge others' pull requests following their best judgement.\n  They may or may not ask for feedback from other maintainers. Follow the Zen\n  of Zig.\n- Currently releases are coordinated with Uber employees, because they can test\n  the version-to-be-released their [big repository][go-monorepo]. If you use\n  `hermetic_cc_toolchain` in production and, more importantly, have a\n  heterogeneous environment (different languages, RBE, different platforms), we\n  encourage you to make yourself known. That way we can work together to\n  validate it before cutting the release.\n\n[^1]: a [mathematical subset][subset]: both can be equal.\n[^2]: Credit: `zig zen`\n\n[ajbouh]: https://github.com/ajbouh/bazel-zig-cc/\n[sysroot]: https://github.com/ziglang/zig/issues/10299#issuecomment-989153750\n[ubsan1]: https://github.com/ziglang/zig/issues/4830#issuecomment-605491606\n[ubsan2]: https://github.com/ziglang/zig/issues/5163\n[transitions]: https://docs.bazel.build/versions/main/skylark/config.html#user-defined-transitions\n[subset]: https://en.wikipedia.org/wiki/Subset\n[universal-headers]: https://github.com/ziglang/universal-headers\n[go-monorepo]: https://www.uber.com/blog/go-monorepo-bazel/\n[pr-83]: https://github.com/uber/hermetic_cc_toolchain/issues/83\n[pr-10]: https://github.com/uber/hermetic_cc_toolchain/issues/10\n[examples]: https://github.com/uber/hermetic_cc_toolchain/tree/main/examples\n","funding_links":[],"categories":["Starlark"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fuber%2Fhermetic_cc_toolchain","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fuber%2Fhermetic_cc_toolchain","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fuber%2Fhermetic_cc_toolchain/lists"}