Coder Perfect

Is static linking in Linux a thing of the past?


In fact, under Linux, the -static gcc flag no longer works. Let me give you an example from the GNU libc FAQ:

Is there any conceivable way to produce a fully functional static build on Linux at this time, or is static linking entirely dead on Linux? I’m referring to a static build, which includes:

Asked by Shcheklein

Solution #1

I think this is very annoying, and I think it is arrogant to call a feature “useless” because it has problems dealing with certain use cases. The biggest problem with the glibc approach is that it hard-codes paths to system libraries (gconv as well as nss), and thus it breaks when people try to run a static binary on a Linux distribution different from the one it was built for.

Anyway, you can get around the gconv problem by setting GCONV PATH to the appropriate location; this allowed me to run binaries created on Ubuntu on Red Hat.

Answered by Ketil

Solution #2

I’m not sure where to go for historical references, but static linking is no longer supported on GNU systems. (I believe it disappeared when libc4/libc5 was replaced by libc6/glibc 2.x.)

Because of the following, the feature was deemed useless:

Try looking through the archives of the LKML and glibc mailing lists from 10 to 15 years ago. I’m quite sure I saw something similar on LKML a long time ago.

Answered by Dummy00001

Solution #3

Static linking is making a comeback!

Answered by nh2

Solution #4

In the Linux environment, static linking doesn’t appear to get much love. Here’s how I see it.

Static linking is often disliked by people who work in the kernel and lower levels of the operating system. Many *nix library developers have spent a career attempting to link a hundred constantly changing libraries together, a work they perform on a daily basis. If you ever want to know which backflips autotools is capable of, go to their website.

Everyone else, on the other hand, should not be expected to devote the majority of their time to this. Static linking will keep you buffered from library churn for a long time. Rather than being forced to upgrade her software’s dependencies whenever new library versions arrive, the developer can do so on her own pace. This is critical for user-facing applications with sophisticated user interfaces that must manage the flow of the multiple lower-level libraries on which they are reliant. That is why I will always support static linking. If you can statically link cross-compiled portable C and C++ code, the world is your oyster, as you can deliver complicated applications to a wide range of platforms more quickly.

There’s a lot to argue with there from many points of view, and it’s great that open source software allows for all of them.

Answered by moodboom

Solution #5

Just because you have to dynamically link to the NSS service doesn’t mean you can’t statically link to any other library. All that FAQ is saying is that even “statically” linked programs have some dynamically-linked libraries. It’s not saying that static linking is “impossible” or that it “doesn’t work”.

Answered by Dean Harding

Post is based on