Unvendor bundled C++ deps (protobuf, abseil, onnx, re2, flatbuffers, coremltools)

[hmaarrfk]

I've been wanting to help unvendor lots of the stuff that this repo depends on.

The list is:

• libprotobuf
• libabseil
• libonnx
  • libonnx for all platforms including windows -- new package onnx-feedstock#146
  • Add libonnx output to the onnx feedstock admin-requests#2087
• libcoremltools (only for OSX)
  • Libcoremltools - new shared C++ library  coremltools-feedstock#35
  • Add libcoremltools output to the coremltools feedstock admin-requests#2088
• re2
• flatbuffers

I'm not really sure how valuable this is, but it is in the spirit of conda-forge as a whole.

So i figured I would ask my AI tools to do the hardest parts of my OSS contributions.

• I have reviewed AI's code
• This code is ready to be read by other humans.

AI's details

Draft — not ready to merge

This branch unvendors several of the C++ dependencies that onnxruntime
bundles and builds from source, so the feedstock instead links the
conda-forge shared libraries.

Blocked on: libcoremltools and libonnx are not yet on conda-forge —
they currently live on the experimental mark.harfouche channel, which
recipe/conda_build_config.yaml adds to channel_sources temporarily. CI
on this PR will fail until those packages are published to conda-forge
proper. Opening as a draft to share the approach and gather feedback.

What this does

onnxruntime 1.26.0 FetchContent-builds and statically links its own copies
of many dependencies. This branch makes it use the conda-forge packages:

Dependency	Change
libprotobuf	host dep; find_package already supported — no patch
libabseil	host dep + patch 0007 (onnxruntime pins an exact-version FIND_PACKAGE_ARGS; abseil's CMake config is ExactVersion, so the constraint must be dropped)
libcoremltools	patch 0006 — CoreML EP links the prebuilt library instead of vendoring the coremltools sources
libonnx	host dep + patch 0008; requires onnxruntime_USE_FULL_PROTOBUF=ON (the conda onnx is full-protobuf). The patch guards onnxruntime's schema registration with ONNX's IsOnnxStaticRegistrationDisabled() so an externally-linked onnx that statically registers schemas does not double-register
re2	host dep; find_package already supported — no patch
flatbuffers	build + host dep; build.sh regenerates the schema headers with the conda flatc (the committed *.fbs.h carry a static_assert pinning the flatbuffers version)

Because onnxruntime_USE_FULL_PROTOBUF=ON is now set, the compiled C++ unit
tests are skipped — they need ONNX's .proto sources, which the libonnx
package does not ship. The recipe's own test section (Python import, CoreML
provider, the C++ consumer test, cmake-package-check) still runs.

Still vendored

cpuinfo (pytorch/cpuinfo) and kleidiai remain vendored and statically
linked — there is no conda-forge package for either yet.

Known limitations

• The conda-forge libonnx does not carry onnxruntime's vendored patch that
  un-deprecates the opset-18 GroupNormalization operator, so models with an
  ai.onnx GroupNormalization node at opset 18–20 are rejected. opset ≥ 21
  is fine. In practice no mainstream exporter emits that operator (they
  decompose group norm), so the impact is minimal.
• Only osx-arm64 has been build-verified locally (a full conda-build:
  both outputs build, link the conda shared libraries, and pass their
  tests). linux and win are unverified.

🤖 Generated with Claude Code

[conda-forge-admin]

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/meta.yaml) and found it was in an excellent condition.

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

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.
• ℹ️ azure.settings_win.variables.MINIFORGE_HOME is deprecated, please use workflow_settings.tools_install_dir instead.
• ℹ️ azure.settings_win.variables.CONDA_BLD_PATH is deprecated, please use workflow_settings.build_workspace_dir instead.

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

[hmaarrfk]

this might be the biggest change. im pretty ok with this but i should triple check that the proto files arent shipped somewhere

[hmaarrfk]

One huge advantage of this is that you can start to have openvino as a runtime (which requires libprotobuf)

[hmaarrfk]

i think the biggest question is whether or not we want to try to unvendor onnx with libonnx. i think it will be worthwhile.

Comments indicating approval on conda-forge/onnx-feedstock#146 would be appreciated.

If we want to keep libonnx vendored, then i can make those changes too.

[cbourjau]

i think the biggest question is whether or not we want to try to unvendor onnx with libonnx. i think it will be worthwhile.

Comments indicating approval on conda-forge/onnx-feedstock#146 would be appreciated.

If we want to keep libonnx vendored, then i can make those changes too.

I gave a small update concerning libonnx in the linked PR. Could/should we unvendor onnx/protobuf and the rest in two separate PRs? There was also work upstream to make the execution providers separate from the main package (e.g. the CUDA kernels don't have to be statically linked to libonnxruntime anymore). I think this would a great thing to make use of in this feedstock. Is it in scope of this exercise, too?

[hmaarrfk]

to understand:

• One PR for unvendoring libonnx
• One PR for unvendoring protobuf and the rest

is that correct?

[hmaarrfk]

(i was thinking about the cuda stuff too, its kinda strange that we have to rebuild the whole thing, but we would need to think about how we would support 12.X and 13.X and so it makes it quite distinct from this exact work for now)

[cbourjau]

to understand:

* One PR for unvendoring libonnx

* One PR for unvendoring protobuf and the rest

is that correct?

I thought:

• One PR for libonnx + protobuf
• One PR for everything else

Might just be that I'm overthinking this, though! My thinking is:

• Landing piece-meal might be faster / no need to block on the libonnx part
• Unvendoring onnx without unvendoring protobuf or the other way around might create other issues (just a hunch)

[hmaarrfk]

Unvendoring onnx without unvendoring protobuf or the other way around might create other issues (just a hunch)

I’m pretty sure I remember this being true.

Also. My AI had trouble with OpenVINO execution provider without working from this branch due to protobuf being vendored.

Will try to break it out into two

[hmaarrfk]

just fyi, the only thing that doesn't depend on absl or protobuf is flatbuffers.

so it will be

• flatbuffers
• everything else.

:/

[hmaarrfk]

part 1: #186 (comment)

[xhochy]

I tried to unvendor libprotobuf in the past, but ran into the issue that both onnxruntime and libonnx try to load the same protobuf definitions. You would probably need to make sure that they are only loaded once (you can only load them multiples times if you have multiple static libprotobuf linkages)

[hmaarrfk]

I have to admit I did not know about the "protobuf initialization challenges", but I have been validating this and using this on my machines. In fact, I believe i addressed the "dual" protobuf initialization is part of the validation I ended up doing this last week. It was admittedly a lot of patching. I think we have generally seen the challenges of "shared protobuf". Arguably there are likely more challenges of having both "shared protobuf" and "static protobuf" when it comes time to linking libraries together.

I believe i should be able to upload the full set of packages to my channel to allow you all to test, can we agree on:

• osx-arm64
• linux-64

As test platforms. My goal is really to enable more runtimes for onnxruntime in a way that is commensurate with the rest of the conda-forge stack, that is to say, we have "worked to unvendor protobuf".

[hmaarrfk]

@cbourjau while i think it would be nice to do it in stages, unvendoring "flatbuffers" is a little boring on itself, and the rest of the unvendoring all depend on absl so they must be done together.

Please find attached instructions and a test script that tests things.

I've uploaded the required packages to my feedstock.

run_all_backends.py

I've tested this on a 2XX series NPU, the 3XX series NPU still crashes for me.

Please let me know if you have concerns:

$ python run_all_backends.py 
reference output: [12.299315   6.9270134  6.7726903]

ONNX Runtime
  [✓] onnxruntime CPU                    PASS  max|diff|=9.54e-07
  [✓] onnxruntime + OpenVINO CPU         PASS  max|diff|=9.54e-07
  [✓] onnxruntime + OpenVINO NPU         PASS  max|diff|=2.67e-03
  [✓] onnxruntime + OpenVINO GPU         PASS  max|diff|=5.14e-03
  [✓] onnxruntime + NVIDIA CUDA          PASS  max|diff|=0.00e+00

OpenVINO (native API)
  [✓] OpenVINO CPU                       PASS  max|diff|=9.54e-07
  [✓] OpenVINO NPU                       PASS  max|diff|=2.67e-03
  [✓] OpenVINO GPU                       PASS  max|diff|=5.14e-03

Summary:
  PASS  onnxruntime CPU                    max|diff|=9.54e-07
  PASS  onnxruntime + OpenVINO CPU         max|diff|=9.54e-07
  PASS  onnxruntime + OpenVINO NPU         max|diff|=2.67e-03
  PASS  onnxruntime + OpenVINO GPU         max|diff|=5.14e-03
  PASS  onnxruntime + NVIDIA CUDA          max|diff|=0.00e+00
  PASS  OpenVINO CPU                       max|diff|=9.54e-07
  PASS  OpenVINO NPU                       max|diff|=2.67e-03
  PASS  OpenVINO GPU                       max|diff|=5.14e-03