DLL Programmer's Guide for TNS/R Systems

Finding Symbol Definitions
DLL Programmer’s Guide for TNS/R Systems—522203-002
4-4
Global Scope, Import and Export
loadfiles (programs and libraries). Furthermore, the application of these concepts
differs from one source language to another.
In C, items declared within a function are local to that function and are undefined
(invisible) elsewhere. Items declared outside any function have global scope and are
visible in any function that doesn't hide that declaration with a local one of the same
name. (In languages with nested functions, such as Pascal, there are multiple levels of
nested scopes. In pTAL, a SUBPROC has a scope nested within that of the PROC.)
The C language defines "storage class" (sometimes also called "linkage"); the two
storage classes that apply to global functions and data are extern and static.
Global data and functions with static linkage are visible to the functions within this
compilation unit, but are local to the compilation, and therefore to the linkfile that
results from the compilation. Global variables with no specified storage class are
implicitly extern. The explicit specification of extern linkage on an uninitialized
variable declares the variable but leaves it undefined; if there are references in this
compilation, they must be linked to a definition in another.
(The pTAL language has no explicit storage class. Everything is effectively extern
except SUBPROCs, which are static.)
When the linker combines multiple linkfiles to build a loadfile, global extern definitions
in one linkfile are available to satisfy references to an undefined symbol in another;
these items are considered global in the resulting loadfile. However, static global items
within each linkfile become local in the loadfile.
A key part of the linker's job is binding global references in one linkfile to definitions in
another. For C compilation units, the linker enforces the language requirement that a
given symbol have at most one definition in the loadfile. For some constructs common
in header files, the C++ language generates definitions in every compilation that
includes the header; the compiler marks these symbols to inform the linker that
multiple definitions are acceptable, and the linker is expected to bind all references to
one of them. Slightly different rules apply to some pTAL definitions, such as data
blocks: the linker will accept multiple definitions, as long as any initialized data is the
same in each.
If none of the linkfiles contributing to a loadfile defines a referenced symbol, it remains
undefined in the loadfile. In this case, it will need to be bound to a definition in some
other loadfile. In such a case, the referencing file is said to import the symbol, and the
defining loadfile is said to export it. In a DLL with globalized import control, it is also
possible for a symbol to be imported even though it is offered for export; in this case
the definition in this DLL is said to be preempted by a definition in a loadfile appearing
earlier in the program's loadList.
Only some of the global symbols in the loadfiles can be shared with other loadfiles:
those that are offered for export, and those that are undefined (require import). There
are several ways that symbols become available for export. By default, the linker offers
for export only symbols that the compiler designates as exportable. With the C/C++
compilers, you can specify export or import of individual symbols, or of whole classes.
With the linker, you can export individual symbols, or you can cause all global symbols