There are 2 arguments for having shared libraries:

  1. It helps reduce disk space.
  2. When a shared library is updated, all the binaries depending on it get the update.

There is mainly one drawback for shared libraries:

  • They (can) introduce dependency hell.

On desktop computers, the 1st advantage doesn't really hold anymore. Wasting disk space isn't much of an issue these days.

Having static binaries would allow us to get way better package managers -- I mean, the dependency hell would be a thing of the past. Adding a program would be just adding a binary; eventually a folder to let it handle its files. Deleting a program would be simply deleting this file. Dependencies? Gone.

The 2nd advantage still stands, but I think the advantage of static binaries on desktop computers outweighs it. I mean, even new languages like Go compile all their binaries in spite of the shared libraries advantages, because of the convenience.

Since one of the main advantages of shared libraries is not a big deal anymore, are C static libraries are still frowned upon? If so, why?

  • 4
    The primary reason that C is used anymore is specifically because you're not working on modern desktop computers.
    – Telastyn
    Commented Aug 28, 2014 at 20:14
  • 19
    @Telastyn I'm sorry? Most of the software installed on my desktop computers is written in C. Commented Aug 28, 2014 at 20:17
  • 6
    Side bit - an off site read on the subject - Dynamic Linking Considered Harmful
    – user40980
    Commented Aug 28, 2014 at 20:48
  • 6
    One benefit of dynamic libraries is that people can still update the libraries to work around bugs, security holes or hardware issues in your 15 year old closed source game that has long since stopped receiving updates. Kind of a niche case but since good games aren't commodities, "just use another program" doesn't really help. It also matters for complying with LGPL without open sourcing your own code.
    – Doval
    Commented Aug 28, 2014 at 21:14
  • 4
    You forgot two other advantages of the shared libraries: 1) they're shared in memory too, 2) all linkers suck badly, and linking a huge binary is highly unpleasant. Splitting a binary into several smaller entities makes the whole process much more tolerable.
    – SK-logic
    Commented Aug 28, 2014 at 22:25

5 Answers 5


The premise of your question is flawed. What is frowned upon is sticking to doctrinaires and absolutes with no understanding of the basis behind them (Cargo Cult Programming ?).

The linked SO answer is an interesting study in that very topic- the Question was about why a compile with -static option was not working, the answer you linked to was nothing more than a rant about not using static linking. If does not discuss why its bad, and demands the OP uses dynamic linking. Its unfortunate it is marked as the correct answer (the answer following has twice as many votes and is the correct answer to the OP's question) because although the correct answer is there, its deeply hidden in amongst a dogmatic opinion.

The real question is what are the pros and cons of static vs dynamic linking and when would one be preferred over the other.

  • 2
    Basile's answer does tell you precisely why he recommends using shared libraries: "Why do you want to link statically your application? It is generally a mistake (because you don't profit from updates to the system dynamic libraries). In particular name service switch facilities from libc wants dynamic libraries." It not a "rant" just because you disagree with it. Commented Aug 29, 2014 at 5:34
  • @Cody The answer linked to has been edited since I called it a rant. The only opinion I hold on static vs dynamic linking is to use the one that appropriate for your needs, and understand the the strengths and weaknesses of the choice rather then fall into cargo cult programming doctrine because "someone said so".
    – mattnz
    Commented Aug 29, 2014 at 9:08
  • Yeah, the "In particular..." part was added. Not sure how that affects its rant status. Of course I'm not advocating cargo cult programming. It's just that proponents of static linking (in my experience) often miss or underestimate the security concerns. Static linking can be very appropriate for one-off utilities, making the app self-contained and therefore distribution much easier. But any app that will be widely deployed or used for production should really link to a shared library. There are no real disadvantages: at this level of app, you already need a deployment process. Commented Aug 30, 2014 at 2:48
  • 1
    Good example of where static linking is appropriate is where I work - large, complex life critical systems. Once a critical module is tested and approved for operation, it's behavior must not change without going through 'the process'. However, no operational and non-life critical parts of the system (billing and reporting) need less robust control and do use dynamic linkage.
    – mattnz
    Commented Aug 31, 2014 at 1:54

From a developer point of view, dynamic linking can often speed up your compile/link/test loop considerably.

From a package management point of view, take libGL, for example. I have approximately a dozen different implementations of it available in my package manager, some generic and some targeting specific graphics cards. If it wasn't dynamically linked, there would have to be a dozen versions of each program that links with libGL, or else you would have to devise an additional layer of abstraction that isn't as efficient as a function call.

Think of a security issue in a popular library like Qt. With dynamic linking, I can just update that one package, instead of having to identify, recompile, and deploy every single package that links in Qt.

Static linking may have advantages in independently-deployed closed source applications, but in open source package management it hurts more than it helps.

  • 2
    This is true (speeding up development), but it's really frustrating that it makes it into production. The canonical example is Firefox. The amount of engineering effort (in the form of hideous hacks) that have gone into speeding up dynamic linking symbol resolution so that Firefox loads in reasonable time is utterly crazy. Much better performance could have been attained with much less engineering cost if they were just willing to static-link all of their in-project code (while still dynamic linking system libraries and plugins, if desired). Commented Aug 29, 2014 at 2:14

Shared libraries are strongly preferred by Linux distribution maintainers for basically your reason #2. It's really important to them that, for instance, when someone finds a security bug in zlib, they don't have to recompile every single one of the programs that uses zlib---not only would it cost them more CPU cycles to do the recompiling, everyone who uses the distro would then have to re-download all of those programs. Meantime, within the set of packages provided by a distribution, dependency hell is not an issue, because everything is tested to work with that set of libraries.

If you're building third-party software that needs libraries that aren't in your distribution, then statically linking those libraries may be less hassle than the alternative, and that's fine.

The other important thing to know is that GNU libc and GCC's libstdc++ both have components that don't work reliably if the library is statically linked. The most common problem is with dlopen, because whatever module you load with dlopen is itself dynamically linked with libc.so.6. So that means now you have two copies of the C library in your address space, and hilarity ensues when they don't agree on which copy of the internal malloc data structure (for instance) is authoritative. It gets worse: a whole bunch of functions that don't appear to have anything to do with dlopen, like gethostbyname and iconv, use dlopen internally (so that their behavior is runtime-configurable). Fortunately, the ABI for libc and libstdc++ is very stable, so you are unlikely to encounter problems dynamically linking them.


I agree with mattnz's last point: this question is a loaded question. It assumes that static linking is bad. I can think of two reasons why this is not the case:

  • Static linking is safe: if a shared library is updated such that an application uses the new one (maybe the new overwrites the old, or the old one is removed), it can introduce risk that the new version breaks the application. This is a code change outside the scope of an official update for the application. It may not have been tested. Static linking sidesteps this by not sharing libraries externally. I hold that this is a disadvantage to shared libraries due to this risk. What if a new version of a shared library introduces a new bug that breaks certain older applications?

  • Static linking ensures an application is more self-contained. While shared libraries can be colocated with the primary executable, often they are deposited in shared locations. Statically linked applications are easier to ensure "portable" in the sense of "not requiring changes to files, directories or settings owned by the OS" (think Windows directory, registry, /etc).

  • Thank you for improving on the advantages I meant to mention. However, if you see most packages provided by Linux distributions for example, they're not statically compiled. It does seem that static compilation is frowned upon, at least from an external point of view. Commented Aug 28, 2014 at 22:03
  • 1
    Dynamic libraries on pretty much every OS out there these days are paged in by demand. Only the pages actually being used are in memory. If multiple applications are using the same functionality, they will share the memory and use less than the static library case. If multiple apps are using different functionality in the same library, both sets of functionality will be paged in, having approximately the same impact as the static approach. Commented Aug 28, 2014 at 23:26
  • @AlanShutko I did struggle and retyped that portion several ways because of what you mentioned. There are no real guarantees either way, even if modern operating systems do in practice offer the efficiency of shared libraries with the overhead of static. I will edit again.
    – user22815
    Commented Aug 29, 2014 at 2:36
  • @Snowman I think the basic point is that on any realistic operating system that provides dynamic linking (I don't know of any OS that uses dynamic linking but not demand paging) your second point doesn't hold water: memory is not actually used unless the function is used, and the memory used by a dynamic library can be shared between different programs using it, making the memory usage for the dynamic version more efficient rather than less. Your first and third reasons are valid, but I'd simply delete the second: with any realistic assumptions, it's just wrong.
    – Jules
    Commented Aug 29, 2014 at 3:20
  • @Jules I agree, it is a point that was problematic and of dubious validity in modern operating systems. I removed it.
    – user22815
    Commented Aug 29, 2014 at 3:23

Static and dynamic libraries each have their own uses. Looking at a single application in scope we get a different idea about what is necessary and what isn't.

Static linking drastically simplifies application deployment. Not having to detect and deal with different versions. Just bake and deploy.

The obvious advantage with dynamic libraries is the ability to apply updates independently.

This is one of the reasons I loathe maven and other similar dynamic linking project builders for java. They expect a single library version to be available at a given url forever and ever. Not understanding the problem that occurs in 10 years when no one can compile the application because all the source and jars are gone.

  • Is there any particular reason why it shouldn't be possible for programs which use FooLib1.8 to be able to include the code for that library in their executable package in a standard way, so as to allow an upgrade utility shipped with FooLib1.9 to upgrade or downgrade it? The way code was stored in Classic Macintosh would have made that pretty easy; is there any reason today's systems shouldn't be able to do it even better?
    – supercat
    Commented Aug 29, 2014 at 15:03
  • @supercat you mean that every version of a given library would be available on the system? Not sure I understand the question. The OP question was directed more towards system wide shared libraries versus static libraries that would be packaged together. Commented Aug 29, 2014 at 15:15
  • My point was that having an executable package include all the libraries it needs shouldn't have to preclude the possibility of upgrading libraries contained therein. Thus, I don't know that I'd consider regard the ability to upgrade things after deployment as an advantage of not bundling an application with its libraries.
    – supercat
    Commented Aug 29, 2014 at 15:48
  • If the license of a given library allows you to distribute it with your package then that is always the preferred way to do it. It reduces the number of external dependencies. Since you would be distributing everything then an upgrade or patching mechanic would operate the same way with static or dynamic. Patching usually based on binary deltas. There would be no difference. Commented Aug 29, 2014 at 16:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.