An important idea in C is separate compilation: several programs can be
compiled at different times and bound together. But the linker is
separate from the C compiler and can't know too much about the details
of C; how can it know how to combine C programs? Although linkers
don't understand C, they do understand machine language and memory
layout, and it is up to each C compiler to translate C programs into terms
that make sense to the linker.
A typical linker combines several object modules produced by a compiler
or assembler together into a single entity, sometimes called a load
module or an executable file, that the operating system can execute directly.
Some of those object modules are given directly as input to the linker;
others are fetched on demand from a library of object modules containing
printf and similar things.
A linker typically views an object module as containing a collection of
external objects. Each external object represents the contents of some part
of the machine's memory and is identified by an external name. Thus
every function not declared static is an external object, as is every
external variable not declared static. Some implementations make
static functions and variables into external objects as well by
transforming their names somehow so that they do not clash with identically
named variables in other source program files.
Most linkers forbid two different external objects in a single load
module to have the same name. However, several object modules to be
combined into a single load module might contain identically-named
external objects. One important job of a linker is to handle these name
conflicts.
The simplest way to handle such a conflict is to prohibit it. This is
surely correct if the external objects are functions: a program that contains
two different functions with the same name should be rejected. The
problem is harder, though, if the objects are variables. Different linkers
handle that situation in different ways;
0 comments: