Update to 2.21.0 by pb01ka · Pull Request #496 · conda-forge/tensorflow-feedstock

pb01ka · 2026-07-07T17:51:43Z

Checklist

Used a personal fork of the feedstock to propose changes
Bumped the build number (if the version is unchanged)
Reset the build number to 0 (if the version changed)
Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
Ensured the license file is being packaged.

Taken from #491

Closes #488

<details><summary>Claude's draft</summary> Bump the feedstock to TensorFlow 2.21.0: - recipe.yaml: version 2.21.0, refreshed sha256, build 0, bazel 7.*, run-dep bumps (protobuf >=6.31.1, tensorboard 2.21, keras 3.12), and CUDA selectors extended to the 13.x series. - Rebase the patch series onto the 2.21.0 source tree. TF 2.21.0 moved third_party/{absl,gpus,eigen3,ducc} under third_party/xla/ and dropped the duplicated TSL tree, so every patch was refreshed; nine obsolete patches were dropped and several new ones added to restore the systemlib (absl / protobuf / gRPC) wiring that 2.21.0 removed. - Patch files keep their original author attribution (Uwe L. Korn, H. Vetinari, Isuru Fernando and others), sourced from the conda-forge feedstock history. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> Add .ci_support/migrations/cuda130.yaml so the feedstock builds a CUDA 13.0 variant alongside CUDA 12.8. The migration is taken from the conda-forge cuda130 migrator (key_add operation, wait_for_migrators: cuda129, c_stdlib 2.28), matching the approach used by pytorch-cpu-feedstock. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

@xla

<details><summary>Claude's draft</summary> TF 2.21.0 changed its build substantially; the feedstock build scripts are reworked to cope, in logical steps: - Compiler: switch the linux build to the conda-forge clang/clangxx 18 toolchain (conda_build_config.yaml). TF 2.21.0 defaults to a hermetic LLVM CC toolchain (rules_ml_toolchain); build_common.sh selects --config=clang_local + --crosstool_top so the conda toolchain and system headers are used instead. - ABI: pin --cxxopt/--host_cxxopt=-fclang-abi-compat=17. clang 18 changed the Itanium mangling of non-type template parameters of dependent type; conda-forge's libabseil/libprotobuf use the older GCC-compatible form, so TF must match it or absl::Cord etc. fail to link. - System libraries: restore TF_SYSTEM_LIBS and, because TF 2.21.0's cc_shared_library does not forward systemlib cc_library linkopts, force-link the systemized libraries (protobuf, grpc, sqlite3, icu, png, jpeg, gif, flatbuffers, snappy, curl, and abseil's ~90 shared objects) so libtensorflow*.so record them as DT_NEEDED. - Caching: restore .bazelrc to a pristine snapshot on every invocation so the per-Python passes do not accumulate duplicate flags (which changed every compile command and defeated all Bazel caching), and add a persistent --disk_cache. - Packaging: fix the XLA header-install path (@local_xla renamed to @xla), chmod build_env writable so rattler-build can clean it up and package every output, and use cp -f for the wheel copy. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> Re-rendered with conda-smithy to pick up the CUDA 13.0 migration and the clang toolchain change: regenerated .ci_support variant files (CUDA 13.0 level1/level3, refreshed CUDA-None variants), the conda-build workflow, and pixi.toml. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> The run dependency was tensorboard >=2.21,<2.22, which is unsatisfiable: no tensorboard 2.21 has been released on PyPI or conda-forge (latest is 2.20.0 on both). This made the tensorflow-base test environment unsolvable. TensorFlow 2.21.0 does not list tensorboard in its wheel REQUIRED_PACKAGES at all; its CI requirement files pin `tensorboard ~= 2.20.0`. Following the meaning of ~=, that is >=2.20.0,<2.21. Pin tensorboard >=2.20,<2.21 to match. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> conda-forge CI fails the linux builds ~12s into the Bazel compile: embed_gpu_specs_gen failed (Exit 127): /bin/bash: xxd: command not found TF 2.21.0's bundled XLA added the genrule @xla//xla/backends/gpu/target_config:embed_gpu_specs_gen, which runs `xxd -i` to embed GPU spec files into generated C++. xxd is not in the conda-forge build image -- it was an undeclared host tool that happened to be present on the maintainer's dev machine (it ships with vim). Add vim to the staging output's build requirements (xxd is not a standalone conda-forge package; vim provides it). Fixes the linux CPU, CUDA and aarch64 jobs, which all fail here identically. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> The osx-arm64 CI build fails 12s into the Bazel compile: error: invalid value '17' in '-fclang-abi-compat=17' Error in child process '/usr/bin/xcrun'. 1 -fclang-abi-compat=17 was added unconditionally to .bazelrc, but it is a linux-specific fix: conda-forge's linux libabseil/libprotobuf use the GCC-compatible pre-clang-18 mangling for dependent non-type template parameters, so the clang-built TF must match. macOS builds with Apple clang (via xcrun), which both rejects the bare '17' value and does not need it (the conda macOS libraries are clang-built already). Emit the --cxxopt/--host_cxxopt=-fclang-abi-compat=17 lines only when target_platform is linux-*. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> The osx-arm64 build fails compiling generated protobuf code: tpu_embedding_configuration.pb.h: fatal error: 'google/protobuf/runtime_version.h' file not found ... logging_initializer.cc: fatal error: 'absl/base/log_severity.h' not found TF 2.21.0's reworked .bazelrc has `common:macos --config=apple-toolchain`, and `common:apple-toolchain` forces @local_config_apple_cc//:toolchain for --crosstool_top, --apple_crosstool_top and --host_crosstool_top. That overrides the recipe's `--crosstool_top=//bazel_toolchain:toolchain` and, crucially, also sets the host/apple crosstool slots the recipe never touched -- so the conda toolchain (which carries -isystem $PREFIX/include) is bypassed entirely and conda's protobuf/abseil headers are invisible. sed the apple-toolchain config to point all three crosstool slots at the conda //bazel_toolchain:toolchain. This restores the pre-2.21 behaviour where the conda toolchain served the macOS build. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> The osx-arm64 build now reaches the link step (~22 min in) and fails: ld: illegal thread local variable reference to regular symbol google::protobuf::internal::ThreadSafeArena::thread_cache_ for arm64 conda-forge's macOS libprotobuf is compiled with PROTOBUF_NO_THREADLOCAL, so it exports ThreadSafeArena::thread_cache_ as a regular (non-TLS) symbol. TensorFlow compiles the same protobuf headers without that macro, so its objects emit a thread-local (TLV) relocation against thread_cache_; the Mach-O linker rejects a TLV reference to a non-TLS definition. (ELF tolerates the mismatch, so linux is unaffected.) Add -DPROTOBUF_NO_THREADLOCAL to --copt and --host_copt for osx so TF's protobuf header compilation matches the ABI of the installed libprotobuf. host_copt is needed too: the failing target is the [for tool] exec build. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> The previous commit added -DPROTOBUF_NO_THREADLOCAL for osx, but protobuf's port_def.inc explicitly rejects it: port_def.inc:731: error: PROTOBUF_NO_THREADLOCAL was previously defined protobuf manages that macro itself and never expects it pre-defined. Revert that change. The underlying osx link error -- ld: illegal thread local variable reference to regular symbol ThreadSafeArena::thread_cache_ -- is a protobuf ABI clash (a non-TLS protobuf object is being linked into libtensorflow_framework.dylib while the systemized protobuf 6.33.5 headers make thread_cache_ __thread); it needs the protobuf systemize-vs-vendor wiring fixed for osx, not a compile define. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> -fclang-abi-compat=17 was gated on target_platform == linux-*, but the linux CUDA variants build with gcc 14 (the cuda128/cuda130 migrators pin the host compiler to gcc, since nvcc needs a gcc host compiler). gcc has no -fclang-abi-compat flag, so it errors out -- a CUDA-build blocker. Tighten the gate to linux AND c_compiler == clang*, i.e. the CPU variants only. The CUDA variants (gcc) and macOS (Apple clang) both correctly skip the flag. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> osx-arm64 fails linking libtensorflow_framework.dylib: ld: illegal thread local variable reference to regular symbol google::protobuf::internal::ThreadSafeArena::thread_cache_ TF 2.21.0's cc_shared_library does not propagate the systemlib protobuf linkopt. On linux build_common.sh force-links -lprotobuf (and the other systemlibs) via LDFLAGS, but the osx branch only added -undefined dynamic_lookup -- which hides undefined regular protobuf symbols yet cannot reconcile the TLS storage class of thread_cache_, so ld rejects the thread-local reference to it as a (regular, undefined) symbol. Force-link conda's libprotobuf for osx via --linkopt/--host_linkopt (host too: the failing target is the [for tool] exec-config link), so thread_cache_ resolves to its TLS definition in libprotobuf.dylib. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> osx-64 CI fails at Bazel analysis: cc_toolchain_suite '//bazel_toolchain:toolchain' does not contain a toolchain for cpu 'darwin_arm64' osx-64 is cross-compiled on an arm64 runner. gen-bazel-toolchain keys the conda cc_toolchain_suite on darwin_x86_64 (target) and darwin_arm64 (build host), but build_common.sh forced --cpu=darwin -- which matches no suite key. Once TF 2.21.0's apple-toolchain config points crosstool_top at that suite, analysis fails. Set TARGET_CPU=darwin_x86_64 so --cpu matches the emitted suite key. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> conda-forge is moving off CUDA 12.8 on linux. Mirror pytorch-cpu-feedstock, which builds CUDA 12.9 + 13.0: replace the local cuda128.yaml migrator with cuda129.yaml and cuda130.yaml copied verbatim from conda-forge/pytorch-cpu-feedstock's .ci_support/migrations/. A rerender follows to regenerate the .ci_support variant files (drops linux_64_cuda_compiler_version12.8*, adds 12.9). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> conda_build_config.yaml pinned c_compiler=clang / version 18 for all of linux. The CUDA variants must build with gcc (nvcc needs a gcc host compiler, and the cuda migrators pin c_compiler_version=14) -- the unconditional clang 18 pin clashed with the migrator and made the rerender ambiguous. Gate the clang pin on cuda_compiler_version == "None" so only the CPU variant uses clang 18; the CUDA variants fall through to the global pinning + migrator (gcc). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> Re-rendered with conda-smithy 3.61.2 / conda-forge-pinning 2026.05.16 to pick up the cuda128 -> cuda129 migrator swap and the clang compiler gating: the linux CUDA variants are now 12.9 and 13.0 (12.8 dropped), and the CPU variant keeps clang while the CUDA variants use gcc. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> The CUDA 13.0 build aborts during Bazel's repository fetch: nvidia_nvshmem: Platform cuda13_x86_64-unknown-linux-gnu is not supported [...] @xla//xla/tsl/cuda:nvshmem_stub depends on @nvidia_nvshmem which failed to fetch TF 2.21.0's nvshmem_stub alias resolves to the hermetic @nvidia_nvshmem redistribution when CUDA libraries are force-included (override_include_cuda_libs=true, which the recipe sets). The pinned NVSHMEM 3.2.5 redist ships only cuda11/cuda12 archives -- no cuda13 -- so the build fails before compiling anything. CUDA 12.x silently worked because a cuda12 archive exists. Add patch 0067 making nvshmem_stub always resolve to the bundled dlopen stub (:nvshmem). conda-forge does not package NVSHMEM and TF's NVSHMEM support (optional multi-GPU collectives) is loaded via dlopen anyway, so the stub is the correct choice for both CUDA 12.9 and 13.0. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> Two source-side CI fixes (a rerender still needs to land separately): - conda_build_config.yaml: restore the unconditional # [linux] clang pin. The `cuda_compiler_version == "None"` selector cannot evaluate at config-parse time, so clang was dropped from every variant and the CPU build regressed to gcc -- XLA's -emit-llvm intrinsic codegen then fails (gcc rejects clang-only flags like -fno-experimental-sanitize-metadata). - recipe.yaml: add cuda-nvrtc-dev to the CUDA-12/13 host deps. It ships targets/<arch>-linux/include/nvrtc.h; without it the hermetic cuda_nvrtc Bazel repo has an empty include/ and the CUDA build aborts with "missing input file @cuda_nvrtc//:include/nvrtc.h". Both pytorch-cpu-feedstock and jaxlib-feedstock list cuda-nvrtc-dev. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> c_compiler_version / cxx_compiler_version / c_stdlib_version belong to conda-forge's `unix` zip_keys group. Under CF_CUDA_ENABLED the cuda migrator adds a second entry (the CUDA variant), so a single-entry clang override desynced the group and made conda-smithy rerender fail ("ambiguous ... we did not find ['18'] ... in c_compiler_version ['14','14']"). conda_build_config.yaml: give each overridden linux key two parallel entries (CPU + CUDA) plus a matching c_stdlib_version block, mirroring jaxlib-feedstock (which also builds XLA with clang alongside CUDA). Includes the conda-smithy re-render. Rerender now succeeds: CPU and CUDA 12.9 render as clang 18; CUDA 13.0 as clang 14 (cuda130 migrator pin). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> The cuda130.yaml migrator carried gcc-era c_compiler_version (14/13), so the CUDA 13.0 variant rendered with clang 14 -- too old for TF 2.21 / XLA and rejected by the recipe's -fclang-abi-compat=17. jaxlib-feedstock handles this by editing its own copy of the CUDA migrators (they carry use_local: true) to pin the clang version it builds with, in lockstep with recipe/conda_build_config.yaml. Follow that: pin c_compiler_version / cxx_compiler_version / fortran_compiler_version to 18 in cuda130.yaml, and add the same explicit clang-18 block to cuda129.yaml (which previously only got clang 18 by fall-through). Both CUDA 12.9 and 13.0 variants now render c_compiler: clang / c_compiler_version: 18, matching the CPU variant. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> The CUDA variants now build with clang (conda_build_config.yaml + the cuda migrators pin clang 18). TF's ./configure failed: UserInputError: Invalid GCC_HOST_COMPILER_PATH provided 10 times because build_common.sh still set GCC_HOST_COMPILER_PATH=${GCC} -- and there is no gcc in a clang build env, so ${GCC} is empty. TF 2.21.0's configure.py only reads GCC_HOST_COMPILER_PATH when TF_CUDA_CLANG=0; with TF_CUDA_CLANG=1 it reads CLANG_CUDA_COMPILER_PATH and clang compiles the CUDA device code directly (--config=cuda_clang). This matches XLA's own cuda_clang_local reference config and jaxlib-feedstock's clang CUDA build. CUDA branch: drop GCC_HOST_COMPILER_PATH/_PREFIX; set TF_CUDA_CLANG=1, TF_NEED_CLANG=1, CLANG_CUDA_COMPILER_PATH / CLANG_COMPILER_PATH to the conda clang. Also stop the later unconditional TF_CUDA_CLANG=0 / TF_NEED_CLANG=0 from clobbering it -- gate them to the non-CUDA build. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> The clang-CUDA build (TF_CUDA_CLANG=1) failed compiling CUDA 13 device code: clang 18's __clang_cuda_runtime_wrapper.h includes headers CUDA 13 removed (texture_fetch_functions.h), and the device pass chokes on __float128 in gcc 15's libstdc++. clang only gained CUDA 13 support in v21 -- clang 18 cannot target CUDA 13 at all. Switch to nvcc for device code with clang 18 as the host compiler: - TF_CUDA_CLANG=0, TF_NVCC_CLANG=1; append `build --config=cuda_nvcc`. - configure.py reads GCC_HOST_COMPILER_PATH on the TF_CUDA_CLANG=0 path and only checks the path exists, so point it at clang -- which is what nvcc uses as host under TF_NVCC_CLANG. - Put nvvm/bin on PATH for nvcc/cicc/ptxas. - Strip TF's hardcoded -fuse-ld=lld from .bazelrc (conda clang has no lld; the cuda_clang config carried it, cuda_nvcc does not). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> The CUDA build passed sm_100/sm_120 (Blackwell) to clang 18, which errors "unsupported CUDA gpu architecture: sm_100". clang 18 only knows up to sm_90. Drop sm_100/sm_120/compute_120 from HERMETIC_CUDA_COMPUTE_CAPABILITIES -> sm_90/compute_90 ceiling, for both the 12.x and 13.x lists. Blackwell support can return with a newer clang. (One of two changes for the CUDA build; the crosstool-routing fix that keeps nvcc-only copts off plain clang is separate.) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> The CUDA build failed because the recipe appended a blanket `--crosstool_top=//bazel_toolchain:toolchain` (the conda plain-clang toolchain) for all variants. cuda_library .cu.cc targets carry nvcc-only copts (-Xcuda-fatbinary=, -nvcc_options=, -x cuda, --cuda-gpu-arch=); forced onto plain clang 18 those are rejected. --config=cuda_nvcc was set but inert because TF's CUDA crosstool was never selected. cuda_library is a plain cc_library, so Bazel resolution cannot route .cu.cc separately. The mechanism that splits device/host is TF's CUDA crosstool, whose host_compiler is the nvcc wrapper (crosstool_wrapper_driver_is_not_gcc): it sends '-x cuda' actions to nvcc 13 and everything else to conda clang 18 (CLANG_CUDA_COMPILER_PATH). Make --crosstool_top per-variant: CPU keeps //bazel_toolchain:toolchain; CUDA uses @local_config_cuda//crosstool:toolchain (+ host_crosstool_top). That CUDA crosstool's cc_toolchain_suite is keyed k8 not x86_64, so the CUDA linux-64 build also sets --cpu=k8 (CC_CPU). Mirrors TF's own config:rocm pattern. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> With the CUDA build routed through TF's CUDA crosstool, host .cc compiles failed: 'sqlite3ext.h' / 'absl/base/log_severity.h' file not found. TF's CUDA crosstool (cuda_configure.bzl) carries none of the conda gen-bazel-toolchain customizations -- its cxx_builtin_include_directories are only clang's own builtins, unfiltered_compile_flags is empty -- so conda's -isystem $PREFIX/include and the LDFLAGS force-link block (baked into //bazel_toolchain for the CPU build) never reach it. In the CUDA branch, append explicit flags: --copt/--host_copt -isystem $PREFIX/include, --linkopt/--host_linkopt -L$PREFIX/lib, and a loop turning the assembled $LDFLAGS (the -lprotobuf/-lgrpc/-labsl_*/... force-link set) into --linkopt/--host_linkopt. Same pattern the osx branch already uses for the Apple crosstool. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> The previous attempt injected conda's header dir with `--copt=-isystem $PREFIX/include`, but Bazel rejects an absolute include path the active toolchain does not declare: hwloc/base64.c: the include path '$PREFIX/include' references a path outside [the execroot] Use CPATH instead. clang reports CPATH directories in `clang -E -v`, so cuda_configure.bzl folds $PREFIX/include into the CUDA crosstool's cxx_builtin_include_directories (declared -> accepted), and clang also searches CPATH at compile time. Export CPATH/CPLUS_INCLUDE_PATH so the cuda_configure repo rule sees them, and pass them via --action_env/--host_action_env so the compile actions do too. Library dirs / force-link libs stay as --linkopt (linkopts are not path-checked). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> TF's CUDA crosstool passes --cuda-path=external/cuda_nvcc to every compile action. On plain C files (e.g. vendored brotli) clang reports "argument unused during compilation: '--cuda-path=...'", which TF's -Werror,-Wunused-command-line-argument turns into a hard error. Add -Qunused-arguments (--copt/--host_copt) for the CUDA build so clang silently ignores command-line arguments that do not apply to a given source file. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> XLA drags absl btree containers into some CUDA device translation units (via protobuf's ExtensionSet). clang's CUDA-device compilation pass mis-parses absl btree.h's `friend iterator;` / `friend const_iterator;` -- where iterator/const_iterator are type aliases resolving to std::conditional<>::type -- as an elaborated-type-specifier referencing a type alias, which C++ forbids (clang bug llvm/llvm-project#29934). Host clang/gcc accept the same header. btree.h is a conda libabseil package header, not part of the TF source tree, so it cannot go through the patch series. In the CUDA branch of build_common.sh, sed the installed header: replace the alias-based friend declarations with `template <...> friend class btree_iterator;` -- friendship to every btree_iterator specialization, a semantically equivalent superset that avoids the alias. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> The CUDA build failed: tensorflow/core/kernels/gpu_prim.h does `#include "cub/iterator/counting_input_iterator.cuh"`, but CUDA 13's cuda-cccl package ships CUB/Thrust/libcudacxx under targets/<arch>-linux/include/cccl/{cub,thrust,cuda,nv} -- and @cuda_cccl//:headers globs the flat include/cub/**, matching nothing. In the CUDA staging step, promote the cccl/ subdir contents up to the flat include/ layout in both the host and build target trees, before they are merged. Also list cuda-cccl explicitly in the CUDA host deps (it was already pulled in transitively via cuda-version). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

…dstock work <details><summary>Claude's draft</summary> Distills the hard-won lessons from the TF 2.21.0 + CUDA 13.0 update effort into a reusable guide: long multi-hour build monitoring, subagent delegation, the rattler-build debug fast-iteration loop, patch hygiene, mirroring sibling feedstocks (pytorch-cpu, jaxlib), validating via build-locally.py, conda-forge zip-group traps, toolchain pitfalls, and anti-patterns that wasted time. Force-added because the conda-smithy .gitignore ignores all root files; kept in root rather than recipe/ so it is not shipped in the package. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> Set github_actions.store_build_artifacts: true (+ artifact_retention_days: 14) so the GHA build jobs publish each config's built .conda packages as a downloadable workflow artifact (14-day retention) — lets PR builds be downloaded and tested before merge/upload. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

…6.05.24.12.35.11 Other tools: - conda-build 26.3.0 - rattler-build 0.65.0 - rattler-build-conda-compat 1.4.14

<details><summary>Claude's draft</summary> 5th and final duplicate-registration manifestation of the systemlib two-.so layout, found by running real GPU ops (import + pip-check, all CI runs, pass because conda-forge runners are GPU-less). With a GPU present TF auto-places ops there; the first host<->device copy aborts: InvalidArgumentError: Multiple OpKernel registrations match NodeDef at the same priority '_Send' device_type: "CPU" and '_Send' device_type: "CPU" _Send/_Recv (and other) kernels are embedded in both libtensorflow_framework.so and libtensorflow_cc.so, so they register twice in the process-global OpKernel registry and FindKernelRegistration errors on the ambiguity. Patch 0077 makes OpKernelRegistrar::InitInternal skip an exact duplicate (same key, kernel_class_name and serialized KernelDef); genuinely distinct kernels are still registered. Mirrors 0072 (OpRegistry) / 0075 (PlatformObjectRegistry). Must be GPU-validated locally since CI cannot exercise it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

<details><summary>Claude's draft</summary> Document at the top of recipe.yaml the upstream XLA bug where JIT (jit_compile=True / keras auto-JIT) crashes emitting the Ampere TF32 tensor-core mma.sync matmul on CUDA 13 ("FloatAttr does not match expected type of the constant" / "Operand is null" -> Failed to emit LLVM IR). Records that it is compiler-side XLA codegen (not packaging), the disable-TF32 workaround, and the corroborating issues jax-ml/jax#20154 and libxsmm/tpp-mlir#870. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Resume this Claude session: ``` claude --resume d2eda4d2-e5f8-4dd0-a194-052aea8a0ff3 ``` </details>

conda-forge-admin · 2026-07-07T17:53:22Z

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/recipe.yaml:

ℹ️ output 0 output overrides versions pinned in the feedstock:
['- In section host: python 3.12.*']
Requirement spec should not list version specifiers to respect conda-forge-pinning. If you need to force another version, please override the pin via conda_build_config.yaml.
ℹ️ 'Free Disk Space' is deprecated.
Deprecated. Use workflow_settings.free_disk_space instead.
Free up disk space before build.
The following components can be cleaned up: apt, cache, docker.
When set to true, only apt and cache are cleaned up.
Set it to the full list to clean up all components.
ℹ️ 'Store Build Artifacts' is deprecated.
Deprecated. Whether to store build artifacts. Use workflow_settings.store_build_artifacts instead.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/30387422812. Examine the logs at this URL for more detail.}

hmaarrfk · 2026-07-07T23:55:13Z

Please confirm you have tested this on real hardware

pb01ka · 2026-07-08T16:08:54Z

Hi @hmaarrfk. Yes, that's my plan. I am gonna find ways to test it on hardware I have with me.

…2026.07.10.17.17.09 Other tools: - conda-build 26.3.0 - rattler-build 0.64.1 - rattler-build-conda-compat 1.4.15

pb01ka · 2026-07-24T19:18:11Z

@hmaarrfk I tried all the artifacts on my Linux and macOS ARM servers. They seem to work well. https://gist.github.com/pb01ka/f7709d37f4054481170460fcde206213 contains the scripts and logs for each of the artifacts. The file name is <artifact_name>.md. I have only one concern in osx_arm64_. Quoting the same here,

Concern

error: operand #1 does not dominate this use
W0000 00:00:1784907821.145450 2081361 optimize_function_graph_utils.cc:634] Ignoring multi-device function optimization failure: INVALID_ARGUMENT: MLIR Graph Optimizer failed: 
error: operand #0 does not dominate this use
W0000 00:00:1784907821.184963 2081361 optimize_function_graph_utils.cc:634] Ignoring multi-device function optimization failure: INVALID_ARGUMENT: MLIR Graph Optimizer failed:

Should we ship osx_arm64_ builds with this or fix it? Please note that tensorflow installed from pip doesn't have this issue.

Please feel free to check all the logs and let me know if there is anything else we can test for.

If it looks good to you then I will simply re-write my commits cleanly and push those. TYSM.

hmaarrfk · 2026-07-25T00:05:24Z

unfortunately, i don't really want to spend any more time on this, i think others feel the same way
#495

perhaps get ready for somebody else to merge it after "2 weeks pass and nobody reviews it".

In 2 weeks, if nobody else wants to review, i'll step as "conda-forge core" as I would for any feedstock, and allow this to be merged in without my thorough technical review.

pb01ka · 2026-07-28T18:18:12Z

The best I could achieve is available in the logs at my gist.

Now I will re-write my part of git history and address the review I received.

Symlink the wheel's linux libtensorflow_framework to the version-scripted copy, ending duplicated-MLIR "different float semantics" JIT failures. Bump clang 18->22 (TF's actual LLVM era): Highway 1.4.0, clang-22 PTX entry, clang-as-CUDA-compiler + lld, versioned driver lookup, explicit -DNDEBUG.

…g.yaml

pb01ka · 2026-07-28T18:27:59Z

I addressed the reviews, and tested the builds from the CI run of the PR on linux and mac servers I have access to. The logs are,

This is the best I could do. See you in two weeks folks (if no reviews received in between).

hmaarrfk added 30 commits May 17, 2026 16:40

hmaarrfk added 4 commits May 24, 2026 10:30

MNT: Re-rendered with conda-smithy 3.61.2 and conda-forge-pinning 202…

a75c53f

…6.05.24.12.35.11 Other tools: - conda-build 26.3.0 - rattler-build 0.65.0 - rattler-build-conda-compat 1.4.14

pb01ka requested review from FarhanTejani, ghego, h-vetinari, hajapy, hmaarrfk, isuruf, jschueller, ngam, njzjz, waitingkuo, wolfv and xhochy as code owners July 7, 2026 17:51

hmaarrfk marked this pull request as draft July 9, 2026 01:13

MNT: Re-rendered with conda-smithy 2026.6.14 and conda-forge-pinning …

0d62363

…2026.07.10.17.17.09 Other tools: - conda-build 26.3.0 - rattler-build 0.64.1 - rattler-build-conda-compat 1.4.15

pb01ka marked this pull request as ready for review July 24, 2026 19:14

h-vetinari reviewed Jul 27, 2026

View reviewed changes

Comment thread recipe/recipe.yaml Outdated

pb01ka added 2 commits July 28, 2026 23:50

Move docstring from recipe.yaml to build_pkg.sh and conda_build_confi…

9a4eab0

…g.yaml

pb01ka force-pushed the update_to_2.21.0 branch from 22bfbc6 to 9a4eab0 Compare July 28, 2026 18:26

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Update to 2.21.0 - #496

Update to 2.21.0#496
pb01ka wants to merge 58 commits into
conda-forge:mainfrom
pb01ka:update_to_2.21.0

pb01ka commented Jul 7, 2026 •

edited

Loading

Uh oh!

conda-forge-admin commented Jul 7, 2026 •

edited

Loading

Uh oh!

hmaarrfk commented Jul 7, 2026

Uh oh!

pb01ka commented Jul 8, 2026

Uh oh!

pb01ka commented Jul 24, 2026

Uh oh!

hmaarrfk commented Jul 25, 2026

Uh oh!

Uh oh!

pb01ka commented Jul 28, 2026

Uh oh!

pb01ka commented Jul 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

pb01ka commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

conda-forge-admin commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hmaarrfk commented Jul 7, 2026

Uh oh!

pb01ka commented Jul 8, 2026

Uh oh!

pb01ka commented Jul 24, 2026

Uh oh!

hmaarrfk commented Jul 25, 2026

Uh oh!

Uh oh!

pb01ka commented Jul 28, 2026

Uh oh!

pb01ka commented Jul 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

pb01ka commented Jul 7, 2026 •

edited

Loading

conda-forge-admin commented Jul 7, 2026 •

edited

Loading