onnxruntime

fe52a3ce - Separate onnxruntime_providers compilation from its archive (#32162)

Separate onnxruntime_providers compilation from its archive (#32162) Supersedes #30511, which GitHub closed automatically when I force-pushed a commit that had lost its parent, and will not let me reopen. The review discussion there is still readable; both of @edgchen1's comments on it are addressed here. ### The change On MSVC shared-library builds the provider sources go into an object library, `onnxruntime_providers_obj`; everywhere else they go into the static library `onnxruntime_providers` as before. Only one of the two exists per configuration, and consumers link `${onnxruntime_providers_target}`, so the condition lives in `onnxruntime_providers_cpu.cmake` alone. `onnxruntime_unittests.cmake` keys off the target's actual `TYPE` rather than re-testing it. The archive is skipped there because with `onnxruntime_ENABLE_LTO` the objects carry whole-program IR, pushing it past the 4 GiB limit `lib.exe` enforces on the COFF archive format (LNK1248). No `lib.exe` option raises that limit, and a shared-library build only needs the objects for the final link. ### Why compilation and packaging are not separate targets An earlier revision always created the object library and materialized the archive from `$<TARGET_OBJECTS:onnxruntime_providers_obj>`. That does not survive the Xcode generator, and failed every iOS job: ``` libtool: can't open file: .../onnxruntime_providers_obj.build/.../Objects-normal/arm64/utils.o (No such file or directory) ``` Xcode flattens a target's objects into one directory and CMake hash-suffixes the filenames when source basenames collide, but `TARGET_OBJECTS` expands to the unsuffixed names. Sources with unique basenames in the same target were written unsuffixed, which is the control. Ninja is unaffected. Two further constraints: * The archive cannot link the object library in any form. Even a `PRIVATE` link is recorded as `$<LINK_ONLY:>`, and `install(EXPORT)` then rejects `onnxruntime_providers` for requiring a target outside the export set. * Consumers go through a variable rather than being repointed at the object library, because `onnxruntime_INTERNAL_LIBRARIES` is consumed both as a link list and as a list of archive *files* — the Apple static-framework prelink in `onnxruntime.cmake`, and `bundle_static_library()` in `onnxruntime_webassembly.cmake`, which collects only `STATIC_LIBRARY` dependencies and would otherwise drop the providers silently. That is also why the condition stays keyed on MSVC. ### Verification Firefox builds onnxruntime on Windows with `cl.exe` from MSVC 14.51.36231 and this exact configuration, so it serves as an A/B — same pinned revision both sides, differing only by this patch: ``` python3 tools/ci_build/build.py --update --parallel --enable_lto --disable_rtti \ --cmake_generator Ninja --build_dir _build --build --build_shared_lib \ --skip_submodule_sync --use_lock_free_queue --skip_tests --config MinSizeRel \ --compile_no_warning_as_error \ --cmake_extra_defines onnxruntime_BUILD_UNIT_TESTS=OFF \ --cmake_extra_defines ONNX_USE_LITE_PROTO=ON \ --disable_exceptions \ --cmake_extra_defines CMAKE_SHARED_LINKER_FLAGS=/MANIFEST:NO ``` Without the patch, x86_64 and i686 both fail, with `onnxruntime_ENABLE_LTO=ON` and `onnxruntime_BUILD_SHARED_LIB=ON` in the generated cache: ``` lib.exe /nologo /LTCG /machine:x64 /LTCG /out:onnxruntime_providers.lib @CMakeFiles\onnxruntime_providers.rsp onnxruntime_providers.lib : fatal error LNK1248: image size (1001DD8D4) exceeds maximum allowable size (FFFFFFFF) ``` That is 4,296,923,348 bytes, roughly 1.9 MB over; the 32-bit build reports 4,300,722,339. The margin is small, consistent with where this surfaced — the same build linked fine until the toolchain moved to 14.51. With the patch, `onnxruntime_providers.lib` is never created, the objects build under `onnxruntime_providers_obj`, and both DLLs link. That configuration is trimmed (`--disable_rtti`, `--disable_exceptions`, lite proto, `MinSizeRel`), so a stock shared+LTO build overflows by at least as much. It also sets `onnxruntime_BUILD_UNIT_TESTS=OFF` with no training or webgpu, so those paths rely on CI here. On Linux the shared, static and forced-object-library configurations all configure and build, with no provider objects in any intermediate archive.