Is it possible to generate a single .so file with LibTorch?

I want to ship a .so file for client usage (same platform). The client does not have LibTorch installed. Can I somehow pack all the depended libraries into one single library for client usages? Thanks!

Bumping up the thread.

I guess you might want to ship your library and statically link every thing else to it.

I don’t understand. How does this solve the problem? For my case it’s OK to use either static library or dynamic library. The point is that the libtorch libraries are mostly dynamic and I cannot pack those into one single object (either static or dynamic). And the question is whether LibTorch can give a compiling option to generate a single object file (instead of a light object with some other deps on libtorch/lib)

In case you want to avoid installing libtorch dependencies on the target system, you might want to rebuild libtorch and also statically link everything to it.

Ah I see. Let me know if my understanding is correct (my CMake / build knowledge is somewhat limited):

The source code in the libtorch distribution should be enough to build the whole package, including all the libraries under libtorch/lib. So if I want to rebuild a single library, I can just discard all the existing lib/... stuff and build from scratch. This is doable since the source code is in whole (nothing hidden or library file only).

Question for me to get started: for the above “build from scratch” step, what do I need to do? Do I need to learn some CMake basics and use/alter libtorch/share/cmake/... accordingly to give me a single static library (and statically linked with my model code) ? Or do I do something else (what should I learn to get started) ? The way I’m building my package currently is to run some simple g++ command (which -L ... -l ... to link to the right shared objects e.g. -ltorch_cpu). I did go through the minimal example in the official installation page as well.

I think the first step is to check which libs you exactly want and which one should be statically linked. If I understand your use case correctly, you don’t want to ask the user to install e.g. MKL, but want to provide it. Besides shipping the library in your installation (and dynamically linking to it), you could thus also directly statically link MKL to your build by setting USE_STATIC_MKL=1 from here.
I don’t know which libraries should be treated in a similar way, but be aware of the common 2GB linker limitation, which could break your build by default if you want to link libs larger than 2GB (there are specific linker args to avoid these issues).

1 Like

I’ll give it a try. Thanks for your help!