1

Suppose you're developing a shared library libshared.so.

And you have a static library libstatic.a with some internal classes and functionality you need. You'd like to link it to your .so like this:

g++ -o libshared.so -shared myObj.o -lstatic

Also you have an executable.sh which will use your .so and dynamically open it in the runtime

dlopen("libshared.so", RTLD_NOW)

You know this executable was as well statically linked against libstatic.a (but you're not sure the version of the library is exactly the same as yours).

So the question is:

Is it safe and correct to statically link your libshared.so against libstatic.a when you know the same library is already used in executable.sh?

Community
  • 1
  • 1
mambo_sun
  • 509
  • 4
  • 13
  • When you static link a library to either an executable or a shared library, the static library becomes a part of the executable or a part of the shared library. So the same library can be linked against multiple components without a problem. However there is a possible problem with different versions of the static library being used which may cause problems with incompatible classes and objects between the different versions of the library. That is a software configuration problem that would require version checking at run time. – Richard Chambers Apr 17 '14 at 12:54
  • The idea of a published library, whether static or dynamic, is to have an API contract which means that the existing interface, classes, objects, etc. do not change. If you are adding additional functionality then rather than changing the existing interfaces you instead add new interfaces so as to keep backwards compatibility. – Richard Chambers Apr 17 '14 at 12:59
  • We do something very similar to this, although we do take pains to ensure we only ever build with the same version of the static library throughout. We recently had a thorny problem where an exception was thrown from the static library by call in the `dlopen`ed library, but couldn't be caught (in the `dlopen`ed lib, yet could in `main()`!). This was resolved by paying careful attention to the third bullet point [here](http://gcc.gnu.org/faq.html#dso). – BoBTFish Apr 17 '14 at 13:01
  • Thanks a lot for a quick answers. @Richard Chambers Thank you for a good point about compatibility, in my case there is no any interoperating (even indirect) between the different versions of the static lib. – mambo_sun Apr 17 '14 at 13:22

1 Answers1

0

You should avoid linking a static library into a shared one.

Because a shared library should have position independent code (otherwise, the dynamic linker has to do too much relocation, and you lose the benefits of shared libraries), but a static library usually does not have PIC.

Read Drepper's paper: How to write a shared library

You build your library with

  g++ -Wall -O -fPIC mySrc.cc -c -o myObj.pic.o
  g++ -o libshared.so -shared myObj.pic.o -lotherlib
Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • And if my static library was compiled with -fPIC option is there anything to be worried about? – mambo_sun Apr 17 '14 at 13:31
  • I am asking because in my shared lib I had a segmentation fault in all virtual functions, which are members of a class (used both in the executable and .so) declared in the static lib. Executable was compiled by someone else, and I only know that it uses my .so and and is statically linked to the library I am using too. And only when I recompiled executable myself, assured that the same version of the static lib is used everywhere the problem has gone. So I am trying to understand the cause of that bug. – mambo_sun Apr 17 '14 at 13:38