Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Build] "nsync_cpp" is not in any export set #16747

Closed
cnd opened this issue Jul 18, 2023 · 8 comments
Closed

[Build] "nsync_cpp" is not in any export set #16747

cnd opened this issue Jul 18, 2023 · 8 comments
Labels
build build issues; typically submitted using template contributions welcome lower priority issues for the core ORT teams

Comments

@cnd
Copy link

cnd commented Jul 18, 2023

Describe the issue

getting:

CMake Error: install(EXPORT "onnxruntimeTargets" ...) includes target "onnxruntime" which requires target "nsync_cpp" that is not in any export set.

I have nsync_cpp installed in system and seems like without onnxruntime_SHARED_LIB cmake flag I don't get the error, but I need shared library

Urgency

can't build shared library for onnxruntime using cmake

Target platform

Linux

Build script

cmake

  -DBUILD_SHARED_LIBS=1
  -Donnxruntime_ENABLE_TRAINING=FALSE
  -Donnxruntime_BUILD_UNIT_TESTS=OFF
  -Donnxruntime_RUN_ONNX_TESTS=OFF
  -DFLATBUFFERS_BUILD_SHAREDLIB=ON
  -DFLATBUFFERS_INSTALL=ON
  -DABSL_ENABLE_INSTALL=ON
  -DCMAKE_INSTALL_LIBDIR=lib
  -Donnxruntime_ENABLE_CPUINFO=OFF

..

make

Error / output

CMake Error: install(EXPORT "onnxruntimeTargets" ...) includes target "onnxruntime" which requires target "nsync_cpp" that is not in any export set.

Visual Studio Version

No response

GCC / Compiler Version

12.3.1 20230623

@cnd cnd added the build build issues; typically submitted using template label Jul 18, 2023
@snnn snnn added the contributions welcome lower priority issues for the core ORT teams label Jul 18, 2023
@snnn
Copy link
Member

snnn commented Jul 18, 2023

Welcome to help us fix it.

@meerfrau
Copy link

@gedoensmax
Copy link
Contributor

Do you really require:

  -DBUILD_SHARED_LIBS=1
  -DFLATBUFFERS_BUILD_SHAREDLIB=ON
  -DFLATBUFFERS_INSTALL=ON
  -DABSL_ENABLE_INSTALL=ON

We saw that this less to failing the build with the above error. I would try reducing as much as possible.

@snnn
Copy link
Member

snnn commented Jan 30, 2024

BUILD_SHARED_LIBS is a standard cmake flag but I'm sorry we do not support it. Most open source libraries are not that flexible that can be built as a static or dynamic library without extra code change. Protobuf is a great example. Protobuf itself is not stateless, if you build it as a shared library, the components who use this shared library will share states, which will cause conflicts. And, namely abseil, a library that most Google's open source libraries use, has very poor support for dynamic linking. These issues cannot be solved at cmake level.

@KottV
Copy link

KottV commented Feb 9, 2024

Afaik there is -Donnxruntime_BUILD_SHARED_LIB=ON for build libonnxruntime.so.1*

@cnd
Copy link
Author

cnd commented Feb 17, 2024

BUILD_SHARED_LIBS is a standard cmake flag but I'm sorry we do not support it. Most open source libraries are not that flexible that can be built as a static or dynamic library without extra code change. Protobuf is a great example. Protobuf itself is not stateless, if you build it as a shared library, the components who use this shared library will share states, which will cause conflicts. And, namely abseil, a library that most Google's open source libraries use, has very poor support for dynamic linking. These issues cannot be solved at cmake level.

This is rather very strange to hear beacuse on release page I can download distrubted shared library, maybe as @KottV said it's just a different flag for it (and I don't really need something specific beyond what is distributed), as for abseil and protobuf for example Gentoo for ages use them as shared ending up with consistent state across whole distribution ecosystem, sure there could be problems with ABI breaking on updates but it's known and solveable with preserving post revers deps rebuilding.

@snnn
Copy link
Member

snnn commented Apr 22, 2024

#20413

@snnn
Copy link
Member

snnn commented Oct 21, 2024

nsync is removed.

@snnn snnn closed this as completed Oct 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build build issues; typically submitted using template contributions welcome lower priority issues for the core ORT teams
Projects
None yet
Development

No branches or pull requests

5 participants