What are linkers and loaders in programming?

920 views

If you had to explain in the shortest and simplest way possible, how would you put it?

In: Engineering

4 Answers

Anonymous 0 Comments

In some programming languages, program code – which is nothing but a text document, is transformed into object code. This is done with a program called a compiler.

Object code is *mostly* the binary CPU instructions that’s going to be your program, but there are omissions. You see, you have one object file over here, and it has to “call” a bit of program somewhere else (a function), but when making the this object file, the compiler didn’t know where that function was. No matter! The compiler just produces a placeholder, and this problem will be taken care of later.

Enter the linker. It’s going to consume object files and and resolve all those placeholders. That function better exist somewhere among all the object files, or it’s an error. The result is an executable binary, either a program, or a library.

Now programs you run all the time. What happens is a loader will read the program into memory, flag that memory as read-only and executable, establish some writeable memory called “the stack”, initialize some data, and coordinate with the operating system to run the program.

Libraries come in two flavors.

Static libraries are glorified object files, they have to be linked into other executables as those are being built by some vendor or producer. Static libraries are one way to distribute *parts* of a program as a product.

Dynamic libraries are far more standalone. It’s not a program by itself, but it can be loaded into memory and used BY programs. There is a boundary call an interface, the library has functions in it called XYZ-whatever, and the program that depends on that dynamic library has to be programmed to know those functions are there and how to use them. Likewise, a program is known to load a dynamic library and depends on an interface, so any library that conforms to that interface can be used by that program (there are layers of security involved, because this is how programs can be exploited). There are benefits to using dynamic libraries, in that you can use them as a plugin system for 3rd party modules and extensions, for whatever such a program might do, you can upgrade just those modules, fix bugs, etc, without having to ship a whole new program, you can reload modules at runtime without stopping the program, and there are higher level things like locating that module in memory in a way to try and evade certain attack vectors (though there are other solutions to this problem, too).

The original idea behind dynamic libraries is that you could save memory by loading a common module into memory once and multiple programs could use it. In practice… I don’t think any operating system actually does this anymore – too many exploits, too vulnerable, too many dependency issues. You can upgrade the common version to fix one program, but it might break another. Many programs will maintain their own copy of otherwise common dynamic libraries, so things don’t get changed and broken under their noses. And the way operating systems handle memory these days makes this an unnecessary practice.

You are viewing 1 out of 4 answers, click here to view all answers.