ChatGPT解决这个技术问题 Extra ChatGPT

Difference between static and shared libraries?

What is the difference between static and shared libraries?

I use Eclipse and there are several project types including Static Libraries and Shared Libraries? Does one have an advantage over the other?

Wikipedia has a good description of the distinction between static, dynamic, and shared libraries.

P
Paolo

Shared libraries are .so (or in Windows .dll, or in OS X .dylib) files. All the code relating to the library is in this file, and it is referenced by programs using it at run-time. A program using a shared library only makes reference to the code that it uses in the shared library.

Static libraries are .a (or in Windows .lib) files. All the code relating to the library is in this file, and it is directly linked into the program at compile time. A program using a static library takes copies of the code that it uses from the static library and makes it part of the program. [Windows also has .lib files which are used to reference .dll files, but they act the same way as the first one].

There are advantages and disadvantages in each method:

Shared libraries reduce the amount of code that is duplicated in each program that makes use of the library, keeping the binaries small. It also allows you to replace the shared object with one that is functionally equivalent, but may have added performance benefits without needing to recompile the program that makes use of it. Shared libraries will, however have a small additional cost for the execution of the functions as well as a run-time loading cost as all the symbols in the library need to be connected to the things they use. Additionally, shared libraries can be loaded into an application at run-time, which is the general mechanism for implementing binary plug-in systems.

Static libraries increase the overall size of the binary, but it means that you don't need to carry along a copy of the library that is being used. As the code is connected at compile time there are not any additional run-time loading costs. The code is simply there.

Personally, I prefer shared libraries, but use static libraries when needing to ensure that the binary does not have many external dependencies that may be difficult to meet, such as specific versions of the C++ standard library or specific versions of the Boost C++ library.


"replace the shared object with ... functionally equivalent, but may [improve] performance": specifically, equivalent caller-facing functionality in semantic use of the API (application programming interface: function signatures and variables including types), but implementation-side functionality may differ in more than perf.: e.g. function always logs to file -> also log to TCP server:port expected in $MY_APP_LOG_SERVER.
"As the code is connected at compile time there are not any additional run-time loading costs. The code is simply there." - yes and no... it's all in the executable image ready to be paged in if execution requires, but - starting from a situation where your program hasn't run recently enough to be in cache - with shared libraries it's possible (sometimes likely or certain) that the OS, a driver or another running program will have already loaded the same shared library your app wants to use, in which case it may be in cache and your program start and run faster.
What some people have failed to mention is that with static libraries the compiler knows which functions your application needs and can then optimize it by only including those functions. This can cut down on library size massively, especially if you only use a really small subset of a really large library!
This answer could be better organized. It would be helpful to make bullet lists for pros/cons or a table to show the differences in each dimension where there is a difference.
When you compile dynamically, you are declaring a dependency that is resolved at run-time. Meeting this dependency requires either (a) carrying a copy of the library with the program, or (b) ensuring the library is installed on the target system before running. This means the deployment of the program becomes more complicated. Static linking puts all these dependencies in the program at compile time, thus, typically, reducing the deployment to a single file.
P
Paul Richter

A static library is like a bookstore, and a shared library is like... a library. With the former, you get your own copy of the book/function to take home; with the latter you and everyone else go to the library to use the same book/function. So anyone who wants to use the (shared) library needs to know where it is, because you have to "go get" the book/function. With a static library, the book/function is yours to own, and you keep it within your home/program, and once you have it you don't care where or when you got it.


C
CraftedCart

Simplified:

Static linking: one large executable

Dynamic linking: a small executable plus one or more library files (.dll files on Windows, .so on Linux, or .dylib on macOS)


佚名

For a static library, the code is extracted from the library by the linker and used to build the the final executable at the point you compile/build your application. The final executable has no dependencies on the library at run time

For a shared library, the compiler/linker checks that the names you link with exist in the library when the application is built, but doesn't move their code into the application. At run time, the shared library must be available.

The C programming language itself has no concept of either static or shared libraries - they are completely an implementation feature.

Personally, I much prefer to use static libraries, as it makes software distribution simpler. However, this is an opinion over which much (figurative) blood has been shed in the past.


+1 for "The C programming language itself has no concept of either static or shared libraries - they are completely an implementation feature."
Hi anon / @Tiger, why you stated "The C programming language itself has no concept of either static or shared libraries - they are completely an implementation feature."? Can you please explain little bit in detail or point me to appropriate reference?
@SunilShahu How the program is compiled and linked is specific to the compiler and linker you are using, i.e. the specific implementation of the language. Language speficications generally do not describe how languages should be implemented or built, only the functionality, syntax, grammar, etc.
@SunilShahu more obvious examples might be JavaScript, for example, where the specification (EcmaScript) describes the features of the language, but it is the different vendors that ship the JS interpreters (browser engines or Node.js, for instance). On the other hand, the Python Programming Language has several implementations. The official one is CPython, but there are others written in other languages.
n
nz_21

Static libraries are compiled as part of an application, whereas shared libraries are not. When you distribute an application that depends on shared libaries, the libraries, eg. dll's on MS Windows need to be installed.

The advantage of static libraries is that there are no dependencies required for the user running the application - e.g. they don't have to upgrade their DLL of whatever. The disadvantage is that your application is larger in size because you are shipping it with all the libraries it needs.

As well as leading to smaller applications, shared libraries offer the user the ability to use their own, perhaps better version of the libraries rather than relying on one that's part of the application


DLL hell as it has been known
"Static libraries are compiled as part of an application" ... static libraries are compiled as static libraries and linked as part of an application
J
Jasmeet

The most significant advantage of shared libraries is that there is only one copy of code loaded in memory, no matter how many processes are using the library. For static libraries each process gets its own copy of the code. This can lead to significant memory wastage.

OTOH, a advantage of static libraries is that everything is bundled into your application. So you don't have to worry that the client will have the right library (and version) available on their system.


executable image is bigger on disk, as well as in memory, when using static libs.
Thats correct, that is what I was alluding to when I said everything is bundled into your application.
Additionally, .so files on *nix systems are kinda shared(dynamic) library.
s
sandwood

On top of all the other answers, one thing not mentionned yet is decoupling :

Let me speak about a real world production code,that I have been dealing with :

A very big software, made of >300 projects (with visual studio), mostly build as static lib and finally all link together in one huge executable , you end up with the following problems :

-Link time is extremely long. You might end up by more than 15min of link, for let's say 10s of compilation time -Some tools are on their knee with such a big executable , like memory check tools that must instrument the code. You might fall into reaching limits that had been seen as fools.

More problematic is the decoupling of your software : on this real world example, headers files of every project were reacheable from any others projects. As a consequence it was extremely easy for one developer to add dependencies; it was just about including the header, because link at the end will allwaws find symbols. It ends up by horrible cycling dependencies and complete mess.

With shared library, it's a bit of extra work because developer must edit the project build system to add the dependent library. I observed that shared library code tends to offer a cleaner code API.


s
snr
-------------------------------------------------------------------------
|  +-  |    Shared(dynamic)       |   Static Library (Linkages)         |
-------------------------------------------------------------------------
|Pros: | less memory use          |   an executable, using own libraries|
|      |                          |     ,coming with the program,       |
|      |                          |   doesn't need to worry about its   |
|      |                          |   compilebility subject to libraries|
-------------------------------------------------------------------------
|Cons: | implementations of       |   bigger memory uses                |
|      | libraries may be altered |                                     |
|      | subject to OS  and its   |                                     |
|      | version, which may affect|                                     |
|      | the compilebility and    |                                     |
|      | runnability of the code  |                                     |
-------------------------------------------------------------------------

s
sun1211
+---------------+---------------------------+------------------------------+
| properties    | Static library            | Shared library               |
+===============+===========================+==============================+
| Linking time  | It happens as the         | Shared libraries             |
|               | last step of the          | are added during             |
|               | compilation process.      | linking process              |
|               | After the program         | when executable              |
|               | is placed                 | file and libraries           |
|               | in the memory             | are added to the memory.     |
+---------------+---------------------------+------------------------------+
| Means         | Performed by linkers      | Performed by operating System|
+---------------+---------------------------+------------------------------+
| Size          | Static libraries are      | Dynamic libraries are        |
|               | much bigger in size,      | much smaller, because        |
|               | because external          | there is only one copy       |
|               | programs are built        | of dynamic library           |
|               | in the executable file.   | that is kept in memory.      |
+---------------+---------------------------+------------------------------+
| External file | Executable file will      | In shared libraries,         |
| changes       | have to be recompiled     | no need to recompile         |
|               | if any changes were       | the executable.              |
|               | applied to external files.|                              |
+---------------+---------------------------+------------------------------+
| Time          | Takes longer to execute   | It is faster                 |
|               | because loading into the  | because shared               |
|               | memory happens every time | library code is              |
|               | while executing.          | already in the memory.       |
+---------------+---------------------------+------------------------------+
| Compatibility | Never has a compatibility | Programs are dependent       |
|               | issue,since all code is   | on having a compatible       |
|               | in one executable module. | library.Dependent program    |
|               |                           | will not work if library     |
|               |                           | gets removed from the system |
+---------------+---------------------------+------------------------------+