CODEWITHSUNDEEP
compilationlinkershared-librariesstatic-librariesicc
user2224350
user2224350

Reputation: 2304

Create a statically linked shared library

Is it possible to create a shared library which is itself statically linked, i.e. it does not depend on other shared libraries?

Let me be a little bit more concrete.. I want to create a shared library, say mylib.so, which makes use of some other special libraries (in my case its intel mkl and openMP). Since I have installed these libraries I can build mylib.so and include it in other programs without any problem. However, if I want to use the library (or the executables including it) on another machine I first have to install all the intel stuff. Is there a way to avoid this? My first try was to add the option -static when building mylib.so but this doesn't seem to do anything..

I'm using icc..

Upvotes: 1

Views: 1008

Answers (1)

Employed Russian
Employed Russian

Reputation: 213576

Is it possible to create a shared library which is itself statically linked, i.e. it does not depend on other shared libraries?

Not on Linux, not when using GLIBC (your shared library will always depend on at least ld-linux*.so*).

I want to create a shared library, say mylib.so, which makes use of some other special libraries (in my case its intel mkl and openMP).

There is no problem1 statically linking Intel MKL and OpenMP libraries into mylib.so -- you just don't want to depend on these libraries dynamically (in other words, you are asking for an impossible thing which you don't actually need).

To do so, you need two things:

  1. Link mylib.so with archive versions of the libraries you don't want to depend on dynamically, e.g. gcc -o mylib.so -shared mylib.c .../libmkl.a ...
  2. The libraries which you want to statically link into mylib.so must have been built with position-independent code (i.e. with -fPIC flag).

Update:

What if the archived version isn't available?

Then you can't link it into your library.

Eg I'm using intel/oneapi/intelpython/latest/lib/libstdc++.so and there is no corresponding .a file..

This is a special case: you wouldn't want to link that version into your library even if it were available.

Instead, your program should use the version installed on the target system.

Having two separate versions of libstdc++ (e.g. one statically linked, and the other dynamically linked) into a single process will end very badly -- either with a crash, or with silent stack or heap corruption.

1 Note that linking in somebody else's library and distributing it may have licensing implications.

Upvotes: 1

Related Questions