I sometimes observe that big projects are split into dynamic libraries and an executable. The libraries are ad-hoc - they contain functionality that is only required by this executable. They also reside in the same repository and build by the same build pipeline as the executable. From my point of view this approach creates additional trouble since we need to deploy not only executable but also libraries. So the question is why it is done this way? Why not just statically link everything and produce single executable?
1 Answers
So the question is why it is done this way? Why not just statically link everything and produce single executable?
There are a few possible reasons:
- If the project is sufficiently large, it may not be possible to link code into a single executable on
x86_64ori686platform (the defaultsmallmemory model limits a single binary to 2GiB or.textand.data), - Even if the binary links fine as a single static executable, it may be much faster to rebuild a shared library. If the ABI didn't change (e.g. a small fix to internal implementation detail), then relinking the full executable is unnecessary if shared library is used. This can greatly speed up edit/build/test cycle.
This may also be solved by using a faster linker (e.g. Gold was significantly faster than BFDld, andlldis faster still). But the project may have been split before Gold andlldbecame available, or it may use a platform to which faster linkers have not been ported. - Even when neither of the two reasons above applies, it may still be desirable to maintain API separation between a given library and its clients if the library is maintained by a different sub-team.
The less of the implementation is exposed, the fewer chances there are to misuse the API or introduce unwanted dependencies on the current implementation, and shared libraries allow maintainers to hide much of the internals via symbol visibility.
Related