c++ - When to use dynamic vs. static libraries - Stack Overflow
to customize your list.
Join the Stack Overflow Community
Stack Overflow is a community of 6.6 million programmers, just like you, helping each other.
J it only takes a minute:
When creating a class library in C++, you can choose between dynamic (.dll) and static (.lib) libraries. What is the difference between them and when is it appropriate to use which?
4,72272556
9,923184977
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).
12.3k83258
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 .
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 &typeid() or type_info::before(), you may get undesirable and surprising results.
18.5k53760
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 betw load in the process memory on demand and can be unlo can be upgraded independently of the rest of the program.
Dll cons: performance impact of the dll loadi versioning problems ("dll hell")
Lib pros: no performance impact as code is always loaded in the proces no versioning problems.
Lib cons: executable/process "bloat" - all the code is in your executable and is loade no reuse/sharing - each product has its own copy of the code.
33.6k1180130
58k11103144
Creating a static library
$$:~/static [32]& cat foo.c
#include&stdio.h&
void foo()
printf("\nhello world\n");
$$:~/static [33]& cat foo.h
#ifndef _H_FOO_H
#define _H_FOO_H
void foo();
$$:~/static [34]& cat foo2.c
#include&stdio.h&
void foo2()
printf("\nworld\n");
$$:~/static [35]& cat foo2.h
#ifndef _H_FOO2_H
#define _H_FOO2_H
void foo2();
$$:~/static [36]& cat hello.c
#include&foo.h&
#include&foo2.h&
void main()
$$:~/static [37]& 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
rm -f foo.o foo2.o libtest.a hello.o
$$:~/static [38]&
creating a dynamic library
$$:~/dynamic [44]& cat foo.c
#include&stdio.h&
void foo()
printf("\nhello world\n");
$$:~/dynamic [45]& cat foo.h
#ifndef _H_FOO_H
#define _H_FOO_H
void foo();
$$:~/dynamic [46]& cat foo2.c
#include&stdio.h&
void foo2()
printf("\nworld\n");
$$:~/dynamic [47]& cat foo2.h
#ifndef _H_FOO2_H
#define _H_FOO2_H
void foo2();
$$:~/dynamic [48]& cat hello.c
#include&foo.h&
#include&foo2.h&
void main()
$$:~/dynamic [49]& cat makefile
hello:hello.o libtest.sl
cc -o hello hello.o -L`pwd` -ltest
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
rm -f libtest.sl foo.o foo
2.o hello.o
$$:~/dynamic [50]&
26.5k57164259
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 H***E used a static lib, but you used a dll instead, and not all the exes are comaptible with it.
14.5k1271115
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 ( 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).
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.
16.9k1975105
A static library must be linked into
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.
For an excellent discussion of this topic have a read of
It goes into all the benefits including being able to insert interposing libraries. More detail on interposing can be found in .
27.1k1167134
Ulrich Drepper's paper on "" 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
binary format, but some discussions are suitable for Windows DLLs as well.
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 ), 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.
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.
2,04621521
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.
30k1154100
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.
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.
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.
37.6k49157251
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?
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.
18.5k34276
Your Answer
Sign up or
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Post as a guest
By posting your answer, you agree to the
Not the answer you're looking for?
Browse other questions tagged
rev .24885
Stack Overflow works best with JavaScript enabled& 求助the dynamic library rld.dll failed to initialize ...
查看: 29465|回复: 11
UID8652988主题阅读权限10帖子精华0积分1金钱18 荣誉0 人气0 在线时间0 小时评议0
Lv.1游侠新人, 积分 1, 距离下一级还需 4 积分
帖子精华0积分1金钱18 荣誉0 人气0 评议0
the dynamic library rld.dll failed to initialize(E1103)怎么破
求大神帮助啊
UID8279214主题阅读权限10帖子精华0积分1金钱36 荣誉0 人气0 在线时间5 小时评议0
Lv.1游侠新人, 积分 1, 距离下一级还需 4 积分
帖子精华0积分1金钱36 荣誉0 人气0 评议0
同样遇到这个问题了，楼主解决了吗？
UID1718524主题阅读权限20帖子精华0积分47金钱1291 荣誉0 人气0 在线时间651 小时评议0
Lv.2游侠会员, 积分 47, 距离下一级还需 153 积分
帖子精华0积分47金钱1291 荣誉0 人气0 评议0
顶起来，我也遇到这个问题了！
UID6249996主题阅读权限40帖子精华0积分508金钱5332 荣誉0 人气6 在线时间2308 小时评议0
Lv.4游侠高级会员, 积分 508, 距离下一级还需 492 积分
帖子精华0积分508金钱5332 荣誉0 人气6 评议0
重新点一遍 又进去了
UID6925158主题阅读权限20帖子精华0积分7金钱102 荣誉0 人气0 在线时间37 小时评议0
Lv.2游侠会员, 积分 7, 距离下一级还需 193 积分
帖子精华0积分7金钱102 荣誉0 人气0 评议0
求同问，关了杀毒软件，重新下载了还是不行
UID8264239主题阅读权限10帖子精华0积分1金钱16 荣誉0 人气0 在线时间0 小时评议0
Lv.1游侠新人, 积分 1, 距离下一级还需 4 积分
帖子精华0积分1金钱16 荣誉0 人气0 评议0
对啊，求助，大神赶快来帮忙
UID8286455主题阅读权限20帖子精华0积分93金钱1933 荣誉0 人气7 在线时间1932 小时评议0
Lv.2游侠会员, 积分 93, 距离下一级还需 107 积分
帖子精华0积分93金钱1933 荣誉0 人气7 评议0
可能有以下几个原因
1.重新修复注册表
2.vc2013两个文件是否***
4.rld文件是否被杀软误删
5.离线游戏
UID8797529主题阅读权限10帖子精华0积分1金钱12 荣誉0 人气0 在线时间0 小时评议0
Lv.1游侠新人, 积分 1, 距离下一级还需 4 积分
帖子精华0积分1金钱12 荣誉0 人气0 评议0
blackpupu 发表于
可能有以下几个原因
1.重新修复注册表
注册表怎么修复啊
UID8841416主题阅读权限10帖子精华0积分1金钱11 荣誉0 人气0 在线时间0 小时评议0
Lv.1游侠新人, 积分 1, 距离下一级还需 4 积分
帖子精华0积分1金钱11 荣誉0 人气0 评议0
The Sims 4\__Installer\vc\vc2013\redist这个文件夹里的两个x64，x86装上就能玩了
UID9050670主题阅读权限10帖子精华0积分2金钱28 荣誉0 人气0 在线时间3 小时评议0
Lv.1游侠新人, 积分 2, 距离下一级还需 3 积分
帖子精华0积分2金钱28 荣誉0 人气0 评议0
vc2013里面没东西啊！这怎么办？
UID9304961主题阅读权限10帖子精华0积分1金钱11 荣誉0 人气0 在线时间0 小时评议0
Lv.1游侠新人, 积分 1, 距离下一级还需 4 积分
帖子精华0积分1金钱11 荣誉0 人气0 评议0
谢谢9楼，安了，现在已经能玩
UID9238824主题阅读权限10帖子精华0积分1金钱16 荣誉0 人气0 在线时间0 小时评议0
Lv.1游侠新人, 积分 1, 距离下一级还需 4 积分
帖子精华0积分1金钱16 荣誉0 人气0 评议0
***64时出现问题怎么办
Powered by您的当前位置是：
&->&the dynamic library
问题：闪点行动3红河中文版游戏运行时提示the dynamic library"rld.dll" failed to initialize，什么原因？
***：蟹么么建议您在关闭杀毒软件的情况下重新***运行该游戏（因为斗蟹上的闪点行动3红河中文版游戏经nod32杀毒软件测试没有病毒，因此请您放心在关闭杀毒软件的情况下***运行该游戏，以免相关运行文件被误杀）
蟹么么温馨提示：
斗蟹上的游戏都是经过相关人员测试可运行的，若你无法运行斗蟹上的游戏，那么请详细的描述清楚，并最
好附上截图予以说明，蟹么么与蟹友将共同为你解决！请一定要支持斗蟹，因为斗蟹有你才会更精彩！
前往提问：
体验更多：
蟹么么推荐专题