File README.static of Package makedumpfile

Overview Repositories Revisions Requests Users Attributes Meta

File README.static of Package makedumpfile

Q: Why is makedumpfile linked statically?

A: To save space.

Loner answer follows.

The secondary kernel runs in a very constrained environment. It cannot use
the whole RAM of the machine, simply because this is the data that should
be saved. Instead, it uses a special portion of RAM that is reserved for
that purpose in the primary kernel. Since this is memory that cannot be
used by the primary kernel (it is basically dead unless there is a kernel
crash, which should be a rare event), it is desirable to keep the size of
the reserved memory as small as possible.

One thing that takes up RAM in the secondary kernel is the root file
system. Now, the makedumpfile binary is also run from this filesystem.
Consequently, initrd must also include all the dynamic libraries that
this binary links against. This can increase the size of the initrd
considerably.

However, we don't need most of that space, because makedumpfile uses only
a fraction of all the code present in the dynamic libraries. In fact, when
makedumpfile is the only user of those libraries in the secondary kernel
environment, the other usual term for these libraries, "shared libraries",
no longer matches reality. It is not shared with anything else in the
system. On the other hand, some libraries are also used by other binaries
in the initrd, so it makes sense to link to them dynamically.

The following libraries are shared with other tools:

libdl
  libz

The following libraries are only used by makedumpfile, and thus should be
linked statically:

libdw
  libebl
  libelf
  libbz2
  liblzma

Static versions of some of the above libraries may not be available in the
distro, so a build-time check is performed, and they fall back to linking
dynamically if necessary.

Places

File README.static of Package makedumpfile

Places