On 04/28/2014 05:17 PM, Andrew Smallshaw wrote:
....
No. The C standards don't even explicitly acknowledge the existence
of a linker (references to "compiliation units" are the nearest
you get), never mind providing a method of providing what are
inevitably platform-specific directions to it.
The standard mentions linkers in footnote 71 (n1570.pdf): "On systems in
which linkers cannot accept extended characters, an encoding of the
universal character name may be used in forming valid external
identifiers.". This is a non-normative footnote, and describes a very
specific special case, so it doesn't count for much.
"The separate translation units of a program communicate by (for
example) calls to functions whose identifiers have external
linkage, manipulation of objects whose identifiers have external linkage
.... Translation units may be separately translated and then later linked
to produce an executable program." (5.1.1.1p1)
The standard does not require that a separate program handle that
process. However, if such a program is used, it seems to me to be
reasonable to use the term "linker" to refer to it. I think it still
makes sense to describe the part of the implementation that handles
linking together translation units as the "linker", even if it isn't
actually a separate program.
"In the set of translation units and libraries that constitutes an
entire program, each declaration of a particular identifier with
external linkage denotes the same object or function." (6.2.2p2)
Those three citations seems to me to be more than enough to qualify as
"explicitly acknowledging the existence of a linker". They don't do much
more than acknowledging it, and there's not much more in the rest of the
standard about linking. The rules about how external linkage works imply
some constraints on how a linker could be implemented, but no details
are given.