0

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?

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
Mike
  • 190
  • 7
  • There are advantages and disadvantages for each. – drescherjm Jun 07 '18 at 19:23
  • 1
    ***it as a part of the project*** Which project? I have dozens of projects many containing 20 or so subprojects and usually several hundred source files maybe a thousand or so source files in some.. I think your focus is on smaller projects where everything is in only 1 project. – drescherjm Jun 07 '18 at 19:25
  • You can make a static library into a dynamic library, you can't do the reverse. – Richard Critten Jun 07 '18 at 19:30
  • Dynamic linking takes time when starting the application. For trivial apps this may be negligible, for larger ones, not so much. The app I work on takes roughly 400-600ms to launch (and yes, that's significant for our use-case), and about 300ms of that is due to the dynamic linker. Also, you can't use LTO across dynamic library boundaries. There's also a (slight) run-time cost to position independant code. – Jesper Juhl Jun 07 '18 at 19:31
  • I don't see how solution size (in terms of how many projects) has anything to do with it. If anything that would make a static library seem like an even worse idea bc it would enlarge the final size of the application and you couldnt update the library without recompiling the whole solution stack. – Mike Jun 07 '18 at 19:35
  • 1
    @Mike larger application size on disk does not necessarily equal larger startup time. It's not that simple. – Jesper Juhl Jun 07 '18 at 19:37
  • There is more to it than "3rd party" and "writing the source yourself". What if you are 5 guys writing an app together? It could be convenient to divide the work into a set of separately tested libraries, even if most of them will never be reused elsewhere. – Bo Persson Jun 07 '18 at 20:13
  • @Mike When linking with static libraries the linker only includes the minimum necessary code into the final executable not the whole static library. – Richard Critten Jun 07 '18 at 20:14
  • Nominating for reopen because there are well understood technical pros and cons, not a matter of opinion. – Maxim Egorushkin Jun 07 '18 at 23:12

2 Answers2

5

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?

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
  • Note: I wasn't trying to rip on either or, I was just wondering if there were and what advantages a static library has to dll. Thanks! – Mike Jun 07 '18 at 19:40
1

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

Ripi2
  • 7,031
  • 1
  • 17
  • 33