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

C++ library SONAME without full version number #21281

Closed
anandvsr opened this issue Jul 8, 2024 · 1 comment · Fixed by #21339
Closed

C++ library SONAME without full version number #21281

anandvsr opened this issue Jul 8, 2024 · 1 comment · Fixed by #21339
Assignees
Labels
api issues related to all other APIs: C, C++, Python, etc. feature request request for unsupported feature or enhancement

Comments

@anandvsr
Copy link

anandvsr commented Jul 8, 2024

Describe the issue

In onnxruntime native so file, the SONAME is with version name.
image
why don't we maintain library version as like

libonnxruntime.so        # is called the linker-name used for linking.
libonnxruntime.so.1      # is called the soname used by the operating system loader.
libonnxruntime.so.1.18.1    # is called the real-name which is updated by the library maintainer.

Refer: baeldung.com/linux/shared-object-filenames

It required a scenario where I build a library/executable, which is used to compile with certain version, say v1.17.3. It become the user of the library/executable also must stay with v1.17.3 I they update the library to 1.18.1 it couldn't find the library libonnxruntime.so.1.17.3.

To reproduce

Download a native library tarball v1.17.3.

Create a simple cpp file with create a empty session.

// sample.cc
#include <onnxruntime_cxx_api.h>
#include <iostream>

int main(){
  Ort::Session session(nullptr);
  std::cout << "Session created successfully!\n";
  return 0;
}

compile it using g++

g++ -o sample sample.cc \
    -Ionnxruntime-linux-x64-1.17.3/include \
    -Lonnxruntime-linux-x64-1.17.3/lib \
    -lonnxruntime

Use LD_LIBRARY_PATH to add the library in search path

LD_LIBRARY_PATH=onnxruntime-linux-x64-1.17.3/lib ./sample

Got output

Session created successfully!

If I run it with v1.18.1 in LD_LIBRARY_PATH, it doesn't work.
Download a tarball v1.18.1

LD_LIBRARY_PATH=onnxruntime-linux-x64-1.18.1/lib ./sample

Got error like

./sample: error while loading shared libraries: libonnxruntime.so.1.17.3: cannot open shared object file: No such file or directory

Urgency

No response

Platform

Linux

OS Version

Ubuntu

ONNX Runtime Installation

Built from Source

ONNX Runtime Version or Commit ID

all version (tried v1.17.3, 1.15.1 and 1.18.1)

ONNX Runtime API

C++

Architecture

X64

Execution Provider

Default CPU

Execution Provider Library Version

No response

@snnn snnn added the feature request request for unsupported feature or enhancement label Jul 8, 2024
@sophies927 sophies927 added the api issues related to all other APIs: C, C++, Python, etc. label Jul 11, 2024
@snnn
Copy link
Member

snnn commented Jul 12, 2024

$ readelf -d libonnxruntime.so | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [libonnxruntime.so.1.19.0]

I will change it.

@snnn snnn closed this as completed in e5f18ba Jul 15, 2024
snnn added a commit that referenced this issue Jul 24, 2024
### Description
Before this change, copy_strip_binary.sh manually copies each file from
onnx runtime's build folder to an artifact folder. It can be hard when
dealing with symbolic link for shared libraries.
This PR will change the packaging pipelines to run "make install" first,
before packaging shared libs .


### Motivation and Context

Recently because of feature request #21281 , we changed
libonnxruntime.so's SONAME. Now every package that contains this shared
library must also contains libonnxruntime.so.1. Therefore we need to
change the packaging scripts to include this file. Instead of manually
construct the symlink layout, using `make install` is much easier and
will make things more consistent because it is a standard way of making
packages.

**Breaking change:**
After this change, our **inference** tarballs that are published to our
Github release pages will be not contain ORT **training** headers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api issues related to all other APIs: C, C++, Python, etc. feature request request for unsupported feature or enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants