Revert ONNX CMake changes#7515
Conversation
4496608 to
e3bb2d3
Compare
09a9f2e to
38ee775
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #7515 +/- ##
=======================================
Coverage 55.25% 55.25%
=======================================
Files 513 513
Lines 32213 32213
Branches 2895 2895
=======================================
Hits 17799 17799
Misses 13620 13620
Partials 794 794 ☔ View full report in Codecov by Sentry. |
07d22d3 to
254f9f6
Compare
justinchuby
left a comment
There was a problem hiding this comment.
Thanks - would it be possible to create a CI pipeline to test the xcode generator?
|
@justinchuby We can, but should be in another PR |
Signed-off-by: Yuanyuan Chen <cyyever@outlook.com>
Signed-off-by: Yuanyuan Chen <cyyever@outlook.com>
Signed-off-by: Yuanyuan Chen <cyyever@outlook.com>
b099eb4 to
e33a42d
Compare
Signed-off-by: cyy <cyyever@outlook.com>
Signed-off-by: cyy <cyyever@outlook.com>
Signed-off-by: cyy <cyyever@outlook.com>
|
One test failing? |
|
@justinchuby Looks like it is flaky. |
Signed-off-by: cyy <cyyever@outlook.com>
Signed-off-by: cyy <cyyever@outlook.com>
There was a problem hiding this comment.
Pull request overview
This PR reverts the CMake object library approach that was causing portability issues on some platforms, as reported in issue #7514. The changes simplify the build system by returning to a more traditional library structure while maintaining the same functionality.
Key changes:
- Reverted from OBJECT libraries (
onnx_object,onnx_proto_object) back to regular libraries - Consolidated compile options and configuration into reusable CMake functions
- Fixed loop variable types in C++ code to use
size_twith explicit casting to avoid type warnings
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
onnx/cpp2py_export.cc |
Changed loop variables from auto to size_t with explicit casting to int for Input/Output calls to avoid signed/unsigned comparison warnings |
cmake/summary.cmake |
Updated target references from object library targets (onnx_object, onnx_proto_object) to regular library targets (onnx, onnx_proto) |
cmake/Utils.cmake |
Added add_onnx_compile_options function to centralize compile options, flags, and library linking; reformatted existing functions for consistency |
CMakeLists.txt |
Removed object library definitions and simplified build to use regular libraries; updated nanobind_add_module to include sources directly instead of linking object libraries |
|
Copilot comments look reasonable |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Yuanyuan Chen <cyyever@outlook.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Yuanyuan Chen <cyyever@outlook.com>
|
@justinchuby Fixed |
|
Thank you |
### Motivation and Context It turns out that the CMake object libraries have portability issues on some platforms. Fixes #7514 --------- Signed-off-by: Yuanyuan Chen <cyyever@outlook.com> Signed-off-by: cyy <cyyever@outlook.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
- #7505 - #7515 - #7524 - #7525 --------- Signed-off-by: cyy <cyyever@outlook.com> Signed-off-by: Justin Chu <justinchuby@users.noreply.github.com> Signed-off-by: Yuanyuan Chen <cyyever@outlook.com> Co-authored-by: Yuanyuan Chen <cyyever@outlook.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
I had a local test which ran this case (similar to ONNXRUNTIME linking with ONNX): # . . .
find_package(ONNX REQUIRED CONFIG)
add_executable(${PROJECT_NAME} test_package.cpp)
target_link_libraries(${PROJECT_NAME} PRIVATE onnx onnx_proto)It compiled and linked fine, building as a dynamic library. But I noticed that using the 1.20.x release, using the same example and built as a dynamic one, I got this: onnx/1.20.1 (test package): Running test()
onnx/1.20.1 (test package): RUN: ./test_package
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
E0000 00:00:1768982174.694810 6980831 descriptor_database.cc:678] File already exists in database: onnx/onnx-ml.proto
F0000 00:00:1768982174.696511 6980831 descriptor.cc:2518] Check failed: GeneratedDatabase()->Add(encoded_file_descriptor, size)
*** Check failure stack trace: ***
@ 0x100202488 absl::lts_20250814::log_internal::LogMessage::Flush()
@ 0x100d6a854 google::protobuf::DescriptorPool::InternalAddGeneratedFile()
@ 0x100e0c928 google::protobuf::internal::AddDescriptors()
@ 0x19c27acb0 ___ZNK5dyld46Loader25findAndRunAllInitializersERNS_12RuntimeStateE_block_invoke
@ 0x19c2b8730 ___ZNK5dyld313MachOAnalyzer18forEachInitializerER11DiagnosticsRKNS0_15VMAddrConverterEU13block_pointerFvjEPKv_block_invoke.204
@ 0x19c2d7540 ___ZNK6mach_o6Header14forEachSectionEU13block_pointerFvRKNS0_11SectionInfoERbE_block_invoke
@ 0x19c2d4164 mach_o::Header::forEachLoadCommand()
@ 0x19c2d59fc mach_o::Header::forEachSection()
@ 0x19c2b8220 dyld3::MachOAnalyzer::forEachInitializer()
@ 0x19c27aa68 dyld4::Loader::findAndRunAllInitializers()
@ 0x19c2828b0 dyld4::JustInTimeLoader::runInitializers()
@ 0x19c27b214 dyld4::Loader::runInitializersBottomUp()
@ 0x19c27b1b4 dyld4::Loader::runInitializersBottomUp()
@ 0x19c27fe50 dyld4::Loader::runInitializersBottomUpPlusUpwardLinks()::$_0::operator()()
@ 0x19c27b530 dyld4::Loader::runInitializersBottomUpPlusUpwardLinks()
@ 0x19c29d04c dyld4::APIs::runAllInitializersForMain()
@ 0x19c25f158 dyld4::prepare()
@ 0x19c25dd04 start
/bin/sh: line 1: 64127 Abort trap: 6 ./test_package
ERROR: onnx/1.20.1 (test package): Error in test() method, line 26
self.run(bin_path, env="conanrun")
ConanException: Error 134 while executingI think that it could be related to the fact that My question is:
Thanks in advance! |
|
@franramirez688 Can you reproduce it with ONNX 1.20.1? If so, could you provide the problematic command? |
@cyyever I just uploaded a little repro-case here: https://github.com/franramirez688/repro-onnx-1_20_1 |
Motivation and Context
It turns out that the CMake object libraries have portability issues on some platforms.
Fixes #7514