C ++静态库

Question

Aside from inclusion of 3rd party software, why would you make a static library for a project. If your writing the source yourself you could just build it as a part of the project and if it's a library to be used more than once wouldn't it make more sense to dynamically link and sit on a run-time library?

Answer 1

Dynamic libraries have a run-time cost due to relocations† because the base and relative load address of the library is unknown until run-time. That is, the function calls and variable access to dynamic libraries are indirect. For this reason the code for shared libraries must be compiled as position-independent code ( -fPIC flag in gcc ).

Whereas with static libraries it can use cheaper program counter relative access even with address-space randomization because the relative position of that static library (object files really) is available to the linker.

Note that calls to virtual functions are resolved through the vtable (which the dynamic linker can patch on load), so that the cost of calling a virtual function is always the same regardless of where that function resides. (IIRC, I may need to double-check this statement).

See How To Write Shared Libraries by Ulrich Drepper for full details.

---

Linking to shared libraries is easier though because they contain a list of other shared libraries they depend upon.

Whereas when linking against a static library one must also link explicitly the dependencies of that static library (because a .a is just a bunch of .o files).

A build system should do extra handling for static libraries so that the user does not have to list static library dependencies every time when linking it.

When linking against a static library the linker only pulls in those .o files from the .a that resolve any unresolved symbols, whereas an entire shared library is loaded at run-time. So that if you have a global object in a .o with constructor/destructor side-effects, those side effects will not happen with a static library unless that global object is linked in. Extra care must be taken to make sure that global object is always linked in .

When linking against a shared librarie residing in a non-standard location, along with -L<path> one must specify -Wl,-rpath=<path> as well for the run-time linker to find the shared library there and/or use -Wl,-rpath=$ORIGIN if the shared library is shipped with the executable. Having to set LD_LIBRARY_PATH is a wrong way .

---

† What is PLT/GOT?

Answer 2

The use of dynamic libraries has three main advantages: a) When you release an update of your app it can live in a DL, which is smaller for downloading from Internet than the whole app. b) If your app is a great RAM eater, then you can load and unload DL as needed. c) Its obvious purpose: share the same code in different apps, in a machine with low resources.

a) May lead to dll hell , where different files, same or different versions, populate the directory tree and mess what app uses what .dll

b) Is only possible if you reserve an excesive amount of stack RAM. Likely bad design.

c) This may be right for broad used libs, like stdio , drivers, and most of OS helpers.

The usage of static libraries avoids a) and b). The disadvantage are that they make the final executable bigger and that, when code changes, they require likely a full re-compilation of the project