When to use dynamic vs static libraries

Question

When creating a class library in C    you can choose between dynamic   dll   so  and static   lib   a  libraries  What is the difference between them and when is it appropriate to use which

User · Answer

Besides the technical implications of static vs dynamic libraries (static files bundle everything in one big binary vs dynamic libraries that allow code sharing among several different executables), there are the legal implications.

For example, if you are using LGPL licensed code and you link statically against a LGPL library (and thus create one big binary), your code automatically becomes Open Sourced (free as in freedom) LGPL code. If you link against a shared objects, then you only need to LGPL the improvements / bug fixes that you make to the LGPL library itself.

This becomes a far more important issue if you are deciding how to compile you mobile applications for example (in Android you have a choice of static vs dynamic, in iOS you do not - it is always static).

User · Answer

If the library is static  then at link time the code is linked in with your executable  This makes your executable larger  than if you went the dynamic route    If the library is dynamic then at link time references to the required methods are built in to your executable  This means that you have to ship your executable and the dynamic library  You also ought to consider whether shared access to the code in the library is safe  preferred load address among other stuff   If you can live with the static library  go with the static library

User · Answer

We use a lot of DLL s    100  in our project  These DLL s have dependencies on each other and therefore we chose the setup of dynamic linking  However it has the following disadvantages    slow startup    10 seconds  DLL s had to be versioned  since windows loads modules on uniqueness of names  Own written components would otherwise get the wrong version of the DLL  i e  the one already loaded instead of its own distributed set  optimizer can only optimize within DLL boundaries  For example the optimizer tries to place frequently used data and code next to each other  but this will not work across DLL boundaries   Maybe a better setup was to make everything a static library  and therefore you just have one executable   This works only if no code duplication takes place  A test seems to support this assumption  but i couldn t find an official MSDN quote  So for example make 1 exe with    exe uses shared lib1  shared lib2 shared lib1 use shared lib2 shared lib2   The code and variables of shared lib2 should be present in the final merged executable only once  Can anyone support this question

User · Answer

A lib is a unit of code that is bundled within your application executable   A dll is a standalone unit of executable code  It is loaded in the process only when a call is made into that code  A dll can be used by multiple applications and loaded in multiple processes  while still having only one copy of the code on the hard drive   Dll pros  can be used to reuse share code between several products  load in the process memory on demand and can be unloaded when not needed  can be upgraded independently of the rest of the program   Dll cons  performance impact of the dll loading and code rebasing  versioning problems   dll hell    Lib pros  no performance impact as code is always loaded in the process and is not rebased  no versioning problems   Lib cons  executable process  bloat  - all the code is in your executable and is loaded upon process start  no reuse sharing - each product has its own copy of the code

User · Answer

A static library must be linked into the final executable  it becomes part of the executable and follows it wherever it goes  A dynamic library is loaded every time the executable is executed and remains separate from the executable as a DLL file   You would use a DLL when you want to be able to change the functionality provided by the library without having to re-link the executable  just replace the DLL file  without having to replace the executable file    You would use a static library whenever you don t have a reason to use a dynamic library

User · Answer

I d give a general rule of thumb that if you have a large codebase  all built on top of lower level libraries  eg a Utils or Gui framework   which you want to partition into more manageable libraries then make them static libraries  Dynamic libraries don t really buy you anything and there are fewer surprises -- there will only be one instance of singletons for instance     If you have a library that is entirely separate to the rest of the codebase  eg a third party library  then consider making it a dll  If the library is LGPL you may need to use a dll anyway due to the licensing conditions

User · Answer

Static libraries are archives that contain the object code for the library  when linked into an application that code is compiled into the executable  Shared libraries are different in that they aren t compiled into the executable  Instead the dynamic linker searches some directories looking for the library s  it needs  then loads that into memory  More then one executable can use the same shared library at the same time  thus reducing memory usage and executable size  However  there are then more files to distribute with the executable  You need to make sure that the library is installed onto the uses system somewhere where the linker can find it  static linking eliminates this problem but results in a larger executable file

User · Answer

Static libraries increase the size of the code in your binary  They re always loaded and whatever version of the code you compiled with is the version of the code that will run   Dynamic libraries are stored and versioned separately  It s possible for a version of the dynamic library to be loaded that wasn t the original one that shipped with your code if the update is considered binary compatible with the original version   Additionally dynamic libraries aren t necessarily loaded -- they re usually loaded when first called -- and can be shared among components that use the same library  multiple data loads  one code load    Dynamic libraries were considered to be the better approach most of the time  but originally they had a major flaw  google DLL hell   which has all but been eliminated by more recent Windows OSes  Windows XP in particular

User · Answer

If your working on embedded projects or specialized platforms static libraries are the only way to go  also many times they are less of a hassle to compile into your application  Also having projects and makefile that include everything makes life happier

User · Answer

C   programs are built in two phases   Compilation - produces object code   obj  Linking - produces executable code   exe or  dll    Static library   lib  is just a bundle of  obj files and therefore isn t a complete program  It hasn t undergone the second  linking  phase of building a program  Dlls  on the other hand  are like exe s and therefore are complete programs   If you build a static library  it isn t linked yet and therefore consumers of your static library will have to use the same compiler that you used  if you used g    they will have to use g      If instead you built a dll  and built it correctly   you have built a complete program that all consumers can use  no matter which compiler they are using  There are several restrictions though  on exporting from a dll  if cross compiler compatibility is desired

User · Answer

A static library gets compiled into the client   A  lib is used at compile time and the contents of the library become part of the consuming executable   A dynamic library is loaded at runtime and not compiled into the client executable   Dynamic libraries are more flexible as multiple client executables can load a DLL and utilize its functionality   This also keeps the overall size and maintainability of your client code to a minimum

User · Answer

If your library is going to be shared among several executables  it often makes sense to make it dynamic to reduce the size of the executables   Otherwise  definitely make it static   There are several disadvantages of using a dll   There is additional overhead for loading and unloading it   There is also an additional dependency   If you change the dll to make it incompatible with your executalbes  they will stop working   On the other hand  if you change a static library  your compiled executables using the old version will not be affected

User · Answer

Creating a static library       static  32  gt  cat foo c  include lt stdio h gt  void foo     printf   nhello world n           static  33  gt  cat foo h  ifndef  H FOO H  define  H FOO H  void foo      endif      static  34  gt  cat foo2 c  include lt stdio h gt  void foo2     printf   nworld n           static  35  gt  cat foo2 h  ifndef  H FOO2 H  define  H FOO2 H  void foo2      endif      static  36  gt  cat hello c  include lt foo h gt   include lt foo2 h gt  void main     foo    foo2           static  37  gt  cat makefile hello  hello o libtest a         cc -o hello hello o -L  -ltest hello o  hello c         cc -c hello c -I pwd  libtest a foo o foo2 o         ar cr libtest a foo o foo2 o foo o foo c         cc -c foo c foo2 o foo c         cc -c foo2 c clean          rm -f foo o foo2 o libtest a hello o       static  38  gt      creating a dynamic library       dynamic  44  gt  cat foo c  include lt stdio h gt  void foo     printf   nhello world n           dynamic  45  gt  cat foo h  ifndef  H FOO H  define  H FOO H  void foo      endif      dynamic  46  gt  cat foo2 c  include lt stdio h gt  void foo2     printf   nworld n           dynamic  47  gt  cat foo2 h  ifndef  H FOO2 H  define  H FOO2 H  void foo2      endif      dynamic  48  gt  cat hello c  include lt foo h gt   include lt foo2 h gt  void main     foo    foo2           dynamic  49  gt  cat makefile hello hello o libtest sl         cc -o hello hello o -L pwd  -ltest hello o          cc -c -b hello c -I pwd  libtest sl foo o foo2 o         cc -G -b -o libtest sl foo o foo2 o foo o foo c         cc -c -b foo c foo2 o foo c         cc -c -b foo2 c clean          rm -f libtest sl foo o foo  2 o hello o      dynamic  50  gt

User · Answer

For an excellent discussion of this topic have a read of this article from Sun   It goes into all the benefits including being able to insert interposing libraries  More detail on interposing can be found in this article here

User · Answer

Ulrich Drepper s paper on  How to Write Shared Libraries  is also good resource that details how best to take advantage of shared libraries  or what he refers to as  Dynamic Shared Objects   DSOs    It focuses more on shared libraries in the ELF binary format  but some discussions are suitable for Windows DLLs as well

User · Answer

You should think carefully about changes over time  versioning  stability  compatibility  etc   If there are two apps that use the shared code  do you want to force those apps to change together  in case they need to be compatible with each other    Then use the dll    All the exe s will be using the same code   Or do you want to isolate them from each other  so that you can change one and be confident you haven t broken the other    Then use the static lib   DLL hell is when you probably SHOULD HAVE used a static lib  but you used a dll instead  and not all the exes are comaptible with it

User · Answer

Others have adequately explained what a static library is  but I d like to point out some of the caveats of using static libraries  at least on Windows     Singletons  If something needs to be global static and unique  be very careful about putting it in a static library  If multiple DLLs are linked against that static library they will each get their own copy of the singleton  However  if your application is a single EXE with no custom DLLs  this may not be a problem  Unreferenced code removal  When you link against a static library  only the parts of the static library that are referenced by your DLL EXE will get linked into your DLL EXE    For example  if mylib lib contains a obj and b obj and your DLL EXE only references functions or variables from a obj  the entirety of b obj will get discarded by the linker  If b obj contains global static objects  their constructors and destructors will not get executed  If those constructors destructors have side effects  you may be disappointed by their absence   Likewise  if the static library contains special entrypoints you may need to take care that they are actually included  An example of this in embedded programming  okay  not Windows  would be an interrupt handler that is marked as being at a specific address  You also need to mark the interrupt handler as an entrypoint to make sure it doesn t get discarded   Another consequence of this is that a static library may contain object files that are completely unusable due to unresolved references  but it won t cause a linker error until you reference a function or variable from those object files  This may happen long after the library is written  Debug symbols  You may want a separate PDB for each static library  or you may want the debug symbols to be placed in the object files so that they get rolled into the PDB for the DLL EXE  The Visual C   documentation explains the necessary options  RTTI  You may end up with multiple type info objects for the same class if you link a single static library into multiple DLLs  If your program assumes that type info is  singleton  data and uses  amp typeid   or type info  before    you may get undesirable and surprising results

User · Answer

Really the trade off you are making  in a large project  is in initial load time  the libraries are going to get linked at one time or another  the decision that has to be made is will the link take long enough that the compiler needs to bite the bullet and do it up front  or can the dynamic linker do it at load time

[c++] When to use dynamic vs. static libraries

Examples related to c++

Examples related to dll

Examples related to shared-libraries

Examples related to static-linking

Examples related to dynamic-linking