Mixing Static Libraries and Shared Libraries

Can I mix static and shared-object libraries when linking?

Looking at this thread you can see that it can be done. The guys at GNU suggest

gcc foo.c -Wl,-Bstatic -lbar -lbaz -lqux -Wl,-Bdynamic -lcorge -o foo.exe

Mixing static libraries and shared libraries

My goal is to link libhelper.a into libtestlib.so. Is that possible on Linux?

Sure. This should do:

gcc -shared -fPIC -o libtestlib.so $(OBJS) \
  -Wl,--whole-archive -lhelper -Wl,--no-whole-archive

libhelper.a was not compiled with -fPIC

It's best to rebuild libhelper.a with -fPIC. If that's not possible, above command will still work on Linux/ix86, but not on e.g. Linux/x86_64.

What is the proper way to build programs that use shared libraries that also have dependancies on static libraries?

If you include libhelper.a into libtestlib.so as above, then simple:

gcc main.c -ltestlib

is all you need. If you insist on linking with libhelper.a, then you must tell the end-user that he must link with e.g.

gcc main.c -ltestlib -lhelper

There is no way to specify that libtestlib.so depends on libhelper.a.

How to mix linking both static and shared libraries with CMake

I don't see the problem. With your static library, you can do this:

target_link_libraries(my_target_or_executable /home/me/somedir/mymagiclib.a)

Or

target_link_libraries(my_target_or_executable -L/home/me/somedir/)
target_link_libraries(my_target_or_executable mymagiclib.a)

I even linked to shared libraries yesterday this way. Because I had a conflict in gcc's address sanitizer library coming from multiple sources.

Notice however the difference with linking to a library, the normal way. For your libtest.a, you do this:

target_link_libraries(my_target_or_executable -ltest)

Notice that you dropped the lib prefix here. But don't do this when you want to specify the library manually.

Linker dependencies when mixing static and shared libraries

1) You can't link a static library against a shared library.

2) You would not need to explicitly link against Foo's dependencies if Foo itself was a DSO

3) You can easily modify the Makefile.PL LIBS section to add extra linker dependencies.

4) Qt is a downright pain to link statically anyway. You're better off just doing the whole dynamic shebang unless you have specific version dependencies and OS/platform limitations. Hint: Even if you do have a 'static' build of Qt, this 'static' build won't include things which it might decides need to be present as loadable modules. Been there.

5) I believe there's a CPAN module (somewhat recent) which provides Qt4 bindings. I've never used it and don't know its status, but it may be worth checking out.

But your best bet is to make Foo a dynamic library.. everyone's happy then.

Is it possible to mix static, multi-threaded, DLL libraries in one project?

Are you talking about libraries compiler with different CRT linking type(static, dll)?
If yes, then it's impossible.

Linking a shared library against a static library: must the static library be compiled differently than if an application were linking it?

You do not have to use PIC code in shared objects (as you have discovered you can use the -mimpure-text option to allow that).

That said, non-PIC code in shared objects are more heavyweight. With PIC code, the text pages in memory are just direct memory mappings of the text pages on disk. This means that if multiple processes are using the shared object, they can share the memory page.

But if you do not have PIC code, when the runtime linker loads the shared object, it will have to apply fixups to the text pages. This means that every processes that uses the shared object will have it's own unique version of any text page that has a fixup on it (even if the shared object is loaded at the same address as copy-on-write only notices that the page was modified and not that it was modified in the same way).

To me, the important issue is whether you will simultaneously have multiple processes running that each load the shared object. If you do, it is definitely worth making sure all the code within the SO is PIC.

But if that is not the case and only a single process has the shared object loaded, it's not nearly as critical.

---

Related Topics