The Linker Is not a Magical Program

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Line 8: Line 8:
Step 3 is, of course, the linking step. Why would I say such an outrageous thing? I've been doing tech support for decades, and I get the following questions again and again:
Step 3 is, of course, the linking step. Why would I say such an outrageous thing? I've been doing tech support for decades, and I get the following questions again and again:
-
# The linker says "abc" is an unresolved symbol.
+
# The linker says <code>abc</code> is an unresolved symbol.
-
# The linker says "def" is defined more than once.
+
# The linker says <code>def</code> is defined more than once.
# Why is my executable so large?
# Why is my executable so large?
Line 15: Line 15:
A linker is a very stupid, pedestrian, straightforward program. All it does is concatenate together the code and data sections of the object files, connect the the references to symbols with their definitions, pull unresolved symbols out of the library, and write out an executable. That's it. No spells! No magic! The tedium in writing a linker is usually all about decoding and generating the usually ridiculously over-complicated file formats, but that doesn't change the essential nature of a linker.
A linker is a very stupid, pedestrian, straightforward program. All it does is concatenate together the code and data sections of the object files, connect the the references to symbols with their definitions, pull unresolved symbols out of the library, and write out an executable. That's it. No spells! No magic! The tedium in writing a linker is usually all about decoding and generating the usually ridiculously over-complicated file formats, but that doesn't change the essential nature of a linker.
 +
 +
By [[Walter Bright]]
 +
 +
This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
 +
 +
 +
 +
Back to [[97 Things Every Programmer Should Know]] home page

Revision as of 19:48, 22 November 2008

Depressingly often (happened to me again just before I wrote this), the view a programmer has of the process of going from source code to an executable in a compiled language is:

  1. Edit source code
  2. Compile source code into object files
  3. Something magical happens
  4. Run executable

Step 3 is, of course, the linking step. Why would I say such an outrageous thing? I've been doing tech support for decades, and I get the following questions again and again:

  1. The linker says abc is an unresolved symbol.
  2. The linker says def is defined more than once.
  3. Why is my executable so large?

Followed by "What do I do now?" usually with the phrases "seems to" and "somehow" mixed in, and an aura of utter bafflement. It's the "seems to" and "somehow" that indicate that the linking process is viewed as a magical process, presumably understandable only by wizards and warlocks. The process of compiling does not elicit these kinds of phrases, implying that programmers generally understand how compilers work, or at least what they do.

A linker is a very stupid, pedestrian, straightforward program. All it does is concatenate together the code and data sections of the object files, connect the the references to symbols with their definitions, pull unresolved symbols out of the library, and write out an executable. That's it. No spells! No magic! The tedium in writing a linker is usually all about decoding and generating the usually ridiculously over-complicated file formats, but that doesn't change the essential nature of a linker.

By Walter Bright

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Programmer Should Know home page

Personal tools