Some of the true craftsmanship in the world we take for granted. One of these things is the common tools on Linux, like ps and ls. Even though the commands might be perceived as simple, there is more to it when looking under the hood. This is where ELF or the Executable and Linkable Format comes in. A file format that used a lot, yet truly understood by only a few. Let’s get this understanding with this introduction tutorial!
Some light reading for the weekend.
Light reading indeed. There’s nothing like curling up with a detailed explanation of file headers after a long day.
Joking aside, on a somewhat related note, I’ve seen a number of libraries that have problems with static linking, and are only reliable when dynamically linked. Does anybody have an explanation or know where I might find one? My google-fu is failing me.
Never seen a library that had troubles being statically linked. I’m sure there are some, but I haven’t seen one. The troubles I’ve run into with statically linked is license issues. A lot of people don’t realize that even LGPL still compels source release if it statically linked instead of dynamic. It has to be LGPL with the static link waiver before it’s okay to use without having to release source.
The instability some libraries face when statically linked could be related to PIC, position independent code. I know special care needs to be taken when you’re doing low level stuff. There are also libraries that dynamically load code using dlopen, or similar mechanism, where it doesn’t matter if you statically linked, it will still load code some code at runtime.
The GNU libc is a good example of the dlopen case, they use it to load nsswitch modules for things like username resolution. The upshot there is that a statically linked 32-bit binary that uses glibc and does things like UID to username mapping won’t run correctly on a 64-bit system that doesn’t have a 32-bit install of glibc and whatever nsswitch modules the system uses.