[Home]
[Search]
[CTG]
[RTL]
[IDDE]
Last update Aug 31, 2002
OPTLINK Operation and Design
This chapter describes the fundamental operating concepts of linkers and modular designed programming. The information contained in this chapter is not required in order to install or to use OPTLINK, but familiarity with it will make your programming tasks much easier to
accomplish.
What's in This Chapter
- How linkers work.
- How to design programs in a modular fashion to best
exploit linker operation.
- Library searching.
- How to best exploit OPTLINK's features.
- Error Messages
Linker Operation
The purpose of a linker is to convert object files into an executable
form by resolving address references that span object module
boundaries. This makes it possible to combine a number of distinct
object modules into a single executable program. In the absence of
such a capability, it would not be possible to create today's complex
systems.
The file format accepted by the linker is rigidly defined; each file
contains all information required to resolve all address references
contained within it, although this may be simply a reference to some
"external" symbol. As the linker processes successive object
modules, such external references may be resolved. If any remain
unresolved after the last module has been processed, the link
operation has failed.
Modularly Designed Programs
Most programs are modularly organized into relatively small sections
that perform a single function or procedure. Each of these smaller
sections may, in turn, call upon others, so that the final program
becomes hierarchical.
Organizing programs in this manner maximizes the opportunity to
re-use code. For example, once you (or someone else) have created
a function to input a single keystroke from the keyboard, you never
need to re-create it. All you have to do is to refer to the function
whenever you need to get keyboard input.
For this strategy to work, it's necessary that organization and formats
follow certain rules. These rules were set forth, for "object modules",
by Intel in their specification for Object Module Format (OMF), and
have been extended by other firms (notably Microsoft and Borland).
In addition to making it easy to re-use common functions and
procedures, modular design has another significant advantage:when
you change a program, only those functions that were actually
changed need to be re-compiled. The entire collection of object
modules that make up your program are re-linked.
Source File Design
To organize a program into a series of object modules, the place to
start is with the program's source file( s). Most high-level language
compilers create a single object file from a single source file, no
matter how many different functions or procedures that file contains.
Originally, if you placed all your functions and procedures into the
same source file, the compiler would put them all into a single object
module. Then, when you need only one of those object modules
later, you'll find that all the other object modules are loaded along
with the one you wanted. To overcome this, it was necessary to
break the source file into a number of smaller source files, each
containing only one (or a few, related) functions. Organizing source
files in this manner tended to complicate maintenance of the
program, but simplified re-use of the code.
The preceding paragraph was true until the introduction of "smart
linking". It is now possible to generate encapsulated functions within
a single object module, yet have only those functions which actually
are used by a specific program linked into the executable file.
OPTLINK recognizes the special records that make this possible and
treats them correctly. However, not all language processors yet
generate the special COMDAT records that make smart linking work.
A compromise that addresses both problems is to combine the
smaller source files into a single larger file for storage and while
editing, but then split it into smaller files before compiling or
assembling it. Details of doing this are outside the scope of this
manual; the thing to keep in mind is the trade-off between ease of
maintenance and ease of re-use, so that you can plan your projects
for maximum effectiveness in both areas.
When you run source files through a compiler or assembler, the
normal output is one or more object modules per file. These
individual modules must still be linked; that is, they must all be
combined into a single executable program, with memory locations
assigned to each symbol in each module, and all references within
each module to symbols which are defined in other modules must
be resolved. This task is a function of OPTLINK.
Object Module Library Design
When a complex program is properly divided into its component
sections, the number of object modules involved can easily become
huge. Just keeping track of all these modules can become a serious
problem.
To solve this problem, the concept of an "object module library" or
"library" was invented. A library is a collection of object modules
combined into a single file, together with an index that makes it
possible to quickly locate any module contained in the library.
Most high-level languages include one or more "run time library"
files as a part of their package, and make extensive use of the
modules it contains. In addition, general software products such as
screen display utilities may be sold as add-on libraries. And you can
combine your own object modules into libraries as well. Thus using
libraries is the way to simplify tracking the numerous modules
involved in a complex program.
Library Searching
While collecting object modules into library files makes it simpler to
keep track of the many modules involved in a typical program, the
use of library files imposes some constraints on the linker program's
operation. Only those modules that are required by the program
being linked need actually be included in the final executable file. A
library contains some form of indexing so that the linker can locate
requested modules readily, without having to search through every
object module stored in the library.
Typically, an object module's original source contains references to
symbols which may be in other object module's source compiled at
approximately the same time, and also contain references to symbols
defined in modules within the libraries being used. These are known
as "external" symbol references, and each time an actual memory
location is assigned to one of these symbols, it is said to "resolve"
the symbol reference.
If any external symbol references remain unresolved after all object
modules have been processed, the linker searches for their
definitions within any libraries that have been specified. Each object
module specified to the linker for inclusion (whether specified
explicitly, or by being located during a library search) may resolve
previous external symbol references, but it may also introduce new
ones that will require resolution.
OPTLINK will search any number of libraries in order to resolve
external references that remain after all supplied object modules
have been processed. The library files to be searched may be
specified either by means of commands embedded in the object
modules, or by explicit commands to OPTLINK. If any references
remain unresolved after all libraries have been searched, OPTLINK
reports an error, but can still create the executable file (see /ONERR
and /ERRORFLAG options).
A significant difference between OPTLINK and other linkers is that
OPTLINK always resolves external references from the first library
(in the supplied or default list of library files) that contains a
definition, even if the reference itself occurs in a subsequent library.
Microsoft LINK and many other linkers resolve such a reference by
using the first definition found after the reference.
OPTLINK Functionality
This section reviews OPTLINK's functional processes performed
when attempting to create a program. It performs a number of
sequential actions to accomplish a successful link.
Reading Object Modules
The first action taken by OPTLINK (after setting all applicable
switches for the current run) is to read all .obj files, in the sequence
in which they are specified in the FILE command. You control the
sequence in which files are read by the sequence in which you
provide them to OPTLINK. In some cases, this is significant. As
OPTLINK reads the files, it collects information about sizes,
segments, and symbols, for use in the later stages of linking.
OPTLINK searches for each file first in the current working (default)
directory, then in the directories named by the OBJ environment
variable, and finally in the directories named by the LIB
environment variable.
If a requested object module cannot be found, operation terminates
with a fatal error.
Search library link
After all object modules named in the input have been read,
OPTLINK then searches through all applicable library (.lib)
modules while any EXTERN symbols remain undefined.
The modules first searched are those named in the command line or
supplied interactively, followed by those named in the input data
(searched in the order in which they were named). The first PUBLIC
symbol encountered that matches an undefined EXTERN is used and
any subsequent occurrences of that symbol as a PUBLIC are
ignored, so the sequence in which libraries are searched may have
significant impact on a program's operation.
After all named libraries have been searched, or if no libraries are
named in the input, the libraries called for by internal records of the
object modules (i. e. requested by the translator which generated the
object modules) are searched unless this capability has been turned
off by the use of the /NODEFAULTLIBRARYSEARCH command.
In library searches, when no path is specified with the library name,
the current default directory is searched first when looking for any
specific .lib file. If none is found there, the path( s) listed in the
LIB environment variable are used. If a requested library module
cannot be found, a warning message is issued but operation
continues.
Assigning Segment Addresses
Physically, every segment must begin on a paragraph boundary (an
address of which the low four bits are all zero). Every segment
referenced in a program is identified by two things:a segment name
and a class name.
The segment name is assigned by you, if you write in assembly
language, when you use the SEGMENT/ENDS declarations. If the
object module was generated by a high level language, the segment
name is assigned by the translator. The class name is also supplied
by you, by means of a modifier you may add to the SEGMENT
declaration. If given, the class name is enclosed in single quotes, as
in:
CODESEG SEGMENT PUBLIC BYTE 'CODE'
In this example, the segment name is CODESEG and the class name
is CODE.
Unless a /PACKCODE or /PACKDATA option switches are used,
OPTLINK combines segments having matching segment and class
names based on their combine type, which may be PUBLIC,
COMMON, PRIVATE, or STACK. PUBLIC segments combine into a
single bigger segment; COMMON segments are assigned the same
address (that is, all use the same memory, at the same time), and
PRIVATE segments are not combined at all. The final attribute of a
segment is its alignment, which may be BYTE, WORD, DWORD, PARA,
or PAGE (corresponding to boundaries at multiples of 1, 2, 4, 16, or
256, respectively).
Within each program, all segments of the same class are loaded in
memory adjacent to each other. If no alignment is specified, PARA is
used.
Segment re-ordering
Segments may be, and often are, collected into groups by language
translators. The difference between segments in a group and those
which are not is that, in a group the applicable segment register is
not changed when moving from one segment to another within the
group. If groups are not used, code to change the segment register is
required whenever the segment changes. Like segments themselves,
the size of any group may not exceed 65,536 bytes.
Collecting relocation information
When all the segments, groups, combine types, and classes have
been sorted out and processed appropriately, addresses are assigned
to all the segments. With all addresses known, relocation tables can
be generated (internal to OPTLINK) which are then used to reconcile
address references.
Assigning public addresses
All public symbols within any object module are identified as such,
and only such public symbols can be addressed from outside the
module. OPTLINK keeps track of the segment and offset values for
each public symbol encountered, both while reading the object
modules and when a library search locates a module that contains a
needed extrn symbol declared to be public.
Reconciling address references
Every standard .obj module normally contains several records
devoted to relocation information. These records, identified in
the OMF documentation as type FIXUPP, are universally
called "fix-ups."
Fix-ups are processed after all segment addresses and symbol
references are known, to perform final reconciliation of cross-module
references.
Writing output files
When all address references have been reconciled, OPTLINK writes
the output executable file and any requested report files.
OPTLINK Error Messages
This appendix lists warnings, plus non-fatal and fatal error messages
generated by OPTLINK. When appropriate, any probable cause
and/or remedy is briefly discussed. The DOS return code and
segmented .exe error flag is set upon OPTLINK encountering either
a Non-Fatal or Fatal error. Warnings have no effect on the code or
flag. See also /ONERROR and /DELEXECUTABLE.
Use this reference to:
- Check or confirm that the error has been reported.
- Discover possible causes for an error.
- Discover possible ways to correct an error.
What's in This Chapter
- How OPTLINK error messages are displayed.
- OPTLINK warning messages.
- OPTLINK non-fatal error messages.
- OPTLINK fatal error messages.
How OPTLINK Errors are Displayed
Each warning and error message, with added information such as
the symbol name or file name involved, is displayed to the STDOUT
device and added to the .map file (if selected) when its triggering
condition is detected. If a log of errors is desired, DOS redirection
may be used.
The following rules apply when displayed: If the file name is known,
it is printed. If the module name is known, it is printed (useful
especially if the file name is .lib). If the error occurs at a known
offset in the file, the offset (in hexadecimal) is printed. If a specific
object record is being worked on, its record type (a number in hex
corresponding to the standard Intel OMF or some extension) is
printed. And in every case, an error number (not significant since
these numbers may vary between OPTLINK versions and/ or other
linkers) is printed followed by the text.
Warning Messages
OPTLINK provides several warnings, which alert the operator to an
inconsistency rather than diagnosing a known error. These messages
indicate code that may not execute as you expect but that does link.
OPTLINK completes its operation and the output file may be usable.
ALIAS Previously Defined
An attempt to alias an already-defined symbol was detected. The
ALIAS directive is ignored.
Bad Checksum
A checksum error was detected in an input file. Perhaps the file has
been corrupted.
Below 100H Cannot Be Initialized
While creating a .com file, an attempt to initialize data areas at an
address lower than 0100h was detected.
Cannot Allocate EMS Blocks
An EMS allocation call failed. The EMS driver has provided
inconsistent information. OPTLINK will use alternative memory
space instead.
Cannot Generate Segmented .COM or .SYS File
A .com or .sys extension was specified as the output file name
when a .def file had also been supplied.
COMMON Combine type overrides others
Multiple combine types were specified for a given named segment.
In such a conflict, the COMMON combine type overrides all others,
and the multiple segments will be combined into a single segment.
Duplicate RESOURCE, Ignored
A second resource was found within the .res file with the same
name and type as one already processed. The second resource is
ignored.
File Not Found
The specified .lib file could not be found in order to complete
command operations. If referring to an .obj file or an indirect
command file, this indicates a fatal error, described later in the fatal
error section.
Heap without DGROUP
Heapsize was defined with no DGROUP or zero length DGROUP.
Causes Windows to crash.
Grouped Segments Have Conflicting Flags
Segments in a single group have different flag settings declared via
the SEGMENTS directive in the .def file. Since a group is a single
physical segment in protected mode, all segments that make up the
group must have the same flags.
This warning may be caused by the fact that any non-default flags
override the default settings. That is, a MOVABLE segment overrides a
FIXED segment, and the whole group becomes MOVABLE.
LINNUMs in Non-CODE Segment
A LINNUM statement was encountered within a data segment.
Missing LIBRARY in .DEF File for .DLL
A .dll extension was specified for the output file, but no LIBRARY
directive appears in the .def file. The .dll is created with default
assumptions.
No Stack
No stack segment was supplied. If a .com or .sys file is being
generated, it is normal; in other cases, be careful.
No Start Address
The end of the last .obj file was reached and start address was not
detected. In assembler programming, start addresses are specified by
putting a label after the END statement. In high level languages,
perhaps the start up modules were not supplied.
Segment Already in Different Group
OPTLINK detected a second attempt to assign a segment to a group.
Each segment can belong to only one group.
Stack Already Declared in Module
OPTLINK detected a second attempt to define a stack segment. Each
program can have only one stack segment. The warning is followed
by the name of the module that first declared a stack.
STACK Combine type overrides others
Multiple combine types were specified for a given named segment.
In such a conflict, the STACK combine type overrides all others, and
the multiple segments will be combined into a single segment.
Start Previously Specified in Module
More than one start address was specified for a program. Start
addresses are specified by putting a label after the END statement.
Only one module should specify a start address. If OPTLINK finds
more than one, it uses the first one encountered.
Symbol in this LIB defined elsewhere
Warning message generated from /WARNDUPS.
Too Many Segments, Trying PACKCODE
The segmented .exe format can hold only 254 segments. This
warning appears when more than 254 segments exist and
/PACKCODE was not specified. OPTLINK automatically invokes
/PACKCODE in an attempt to reduce the segment count to a number
below 255.
Too Many Segments, Trying PACKDATA
The segmented .exe format can hold only 254 segments. This
warning appears when more than 254 segments exist after OPTLINK
attempted to /PACKCODE, and /PACKDATA was not specified.
OPTLINK automatically invokes /PACKDATA in an attempt to reduce
the segment count to a number below 255.
Unknown Option
OPTLINK encountered a misspelled, incomplete, or unsupported
option switch.
Unsupported GRPDEF Type
An invalid GRPDEF record was encountered. The bad record is
ignored.
Non-Fatal Error Messages
These are errors which may make the output file unusable, but did
not prevent OPTLINK from completing successfully. Processing
continues if any of these errors are detected, but the output file that
is generated should not be used.
.EXE Header > 64k
The resident portion of a .dll or .exe header approaches or
exceeds 64Kb. Windows loads this header into a single segment;
therefore, it must be smaller than 64Kb. The sizes of the various
pieces that make up the header are listed. You probably need to
import/export by ordinal to reduce name table sizes.
Bad COMDEF Sizes
An size error was detected in a COMDEF record.
Badly Formed Segment Size
The BIG bit was set and segment size was not zero.
BYTE Out of Range
Code such as:
mov al, ext_abs
where ext_abs is greater than 255, was encountered.
Cannot Export
Symbol cannot be exported. It may be either undefined or a
constant. Symbols must have an associated segment to be exported.
Cannot Reach TARGET from FRAME
A traditional "fixup overflow" was detected by OPTLINK. Usually
caused by: memory-model conflicts, a segment or group being too
large, segment order or combining errors (look at the map file
output to diagnose this), incorrect ASSUME statements, trying to
access a variable when no segment register points to it, or trying to
do a NEAR CALL / NEAR JMP to a FAR routine.
CEXTDEF With No COMDAT
The end of an object file was reached and a CEXTDEF item remains
unresolved.
COMDAT Continuation Mismatch
A COMDAT continuation record appears before the COMDAT
definition to which it refers. If you get this error, please contact
Digital Mars Technical Support.
COMDAT Syntax
Due to either corrupt files, translator errors, internal errors in
OPTLINK, or unknown enhancements to the OMF conventions. If
you get this error, please contact Digital Mars Technical Support.
Constants Must Have FRAME=0
A constant having a FRAME value other than zero was detected.
While not prohibited in Intel's OMF format, this is not valid in the
Microsoft version.
CODE Directive
A syntax error was detected in a CODE directive.
DATA Directive
A syntax error was detected in a DATA directive.
Data Outside Segment Bounds
OPTLINK found more data in an object module than expected. For
example, an object file that indicates 5 bytes of data are to follow,
and then provides 6, will cause this error. Most likely cause is that
the object file has been corrupted, or that a translator error has
occurred.
Data Overlaps Relocations
Displayed while the /RELOCATIONCHECK option was in effect and
an overlap was detected. Probable causes include initialization of the
COMMON segment in more than one module, use of the ORG
statement to back up over existing code, or a translator error. The
problem must be resolved, or all other addresses referenced in the
output file may be wrong since relocation information is often stored
as in-place linked lists.
Delimited String Expected
OPTLINK failed to find a delimited string required by the directive
syntax being parsed.
DGROUP + Stack + Heap Exceeds 64K - 16
The total sizes of Heap, Stack, and DGROUP exceed 65,520 bytes.
Try reducing the size of the stack or the heap, or use HEAPSIZE
MAXVAL.
Duplicate OLD
A second OLD directive was encountered.
Duplicate ORDINAL Number
The ordinal number specified for this symbol was already specified
for use by another symbol. Two exported symbols cannot have the
same ordinal number.
Duplicate RC Commands
Both the RC directive in the .def file and the /RC option switch
were supplied. Eliminate one of the two to correct the error.
Duplicate STUB
A second STUB directive was encountered.
EXETYPE Directive
A syntax error was detected in an EXETYPE directive.
EXPORTS Directive
A syntax error was detected in an EXPORTS directive.
_Export Conflicts With EXPORTS
OPTLINK detected a symbol with a different name or parameter list
size in the .def file than was present in the .obj file. They should
agree.
FIXUPP Points Past Data Record
OPTLINK detected a situation such as a FIXUPP record instructing
that the doubleword beginning at byte 5 of a data record be
changed, when the data record contains only six bytes (since a
doubleword beginning at byte 5 would extend through byte 8). Most
likely, the .obj file has been corrupted or a translator error
occurred.
GROUP Cannot Be Both Relocatable and Absolute
A segment defined as SEGMENT AT was placed within a GROUP
with a normal relocatable segment.
Group Cannot Contain CODE and DATA Segments
Segments in the same group have different type flag settings, via the
SEGMENTS directive in the .def file or their class names. Since a
group is a single physical segment in protected mode, the type for
the whole group must be either code or data. It cannot contain both
types.
Group Size Exceeds 64k
The total size of all segments named within a Group exceeds 65,536
bytes.
Groups Overlap
An overlap of groups was detected. In protected mode, groups are
logical segments, and cannot be permitted to overlap. To reorder
segments in such a way that the overlap is eliminated, use
/REORDERSEGMENTS.
HEAPSIZE Directive
A syntax error was detected in a HEAPSIZE directive.
Illegal Frame On Start Address
Detected a FIXUPP error on the start address. Check the module
defining the start address.
Illegal Start Address
An absolute address was used as a start address in relocatable mode.
Correct the address.
IMPORT Illegal As Start Address
The start address was specified as a symbol imported from another
library. This is illegal. The start address must be in the .exe, not in a
.dll.
IMPORTS Directive
A syntax error was detected in a IMPORTS directive.
LOCATION Not Within FRAME
A CALL or JMP was made and the CS ASSUME is not valid.
Library Error
A library problem was detected. The most likely cause is a corrupted
library dictionary.
LINSYM Before COMDAT
A LINSYM record points to a non-existent COMDAT record. Most
likely, caused by either an invalid forward reference or a translator
error.
Multiple Descriptions
More than one DESCRIPTION directive was encountered in a .def
file.
Only One NAME or LIBRARY Allowed
More than one NAME or LIBRARY directive was detected in a .def
file.
Preload Segment + Relocs > 64k, Use -k
A segment marked for preloading, plus its relocation information,
exceeds 65, 536 bytes in size. The fast-load section of a Windows
.exe file cannot accept segments larger than this. You can change
the segment to movable, discardable, loadoncall, or disable segment
sorting with -k.
Previous Definition Different
PUBLIC symbol was redefined and the second definition differs
from the first.
PROT vs REAL Conflict
A conflict between real mode and protected mode syntax was
encountered.
PUBDEF Must Have Segment Index
OPTLINK encountered a PUBLIC symbol that had no reference into
a defined SEGMENT. Most likely cause is a corrupt object file, due
either to a disk accident or translator error.
Relocatable Bases Not Allowed in Absolute Mode
Reference to relocatable data was encountered while processing
code in Absolute Mode. That is, the .obj module(s) cannot
reference segments or groups, cannot do far jumps or calls, and
cannot do DD LABEL, when generating a .com or .sys file, unless
the target segment has been declared to be absolute (SEGMENT AT).
Segment >= 4G
The total size of a 32-bit segment exceeds 4 gigabytes (" 4G").
Segment Size Exceeds 64k
The total size of a segment exceeds 65, 536 bytes (" 64K").
SEGMENTS Directive
A syntax error was detected in a SEGMENTS directive.
Short JMP Out of Range
The destination of short JMP instruction was more than 125 bytes
from the location of the instruction.
Start Address Must Be 100H
The .com file option has been selected and a starting address (END
start_addr) other than 0100h was also specified.
Symbol Undefined
A symbol remained undefined after all input files, including libraries,
had been processed. Common causes for this are:
Too Many ENTRIES
More than 65,536 entries were specified.
Too Much DEBUG Data for Old CodeView Format
OPTLINK detected more than 64KB of debug information per type
per module, and the CodeView option has been enabled for a
CodeView version prior to 4.0.
Unknown COMDAT Allocation Type
Either corrupt files, translator errors, internal errors in OPTLINK, or
unknown enhancements to the OMF conventions. If you get this
error, please contact Digital Mars Technical Support.
Unrecognized data in .CFG
Syntax error within optlinks.cfg.
Unrecognized FIXUPP Type
Most likely cause is the object file has been corrupted, or a translator
error has occurred.
Unrecognized Record
A record in an object file cannot be recognized as one of the defined
record types. The unrecognized record is skipped and linking
continues.
Weak EXTRN Different
A "weak EXTERN" declared with a different default in another
module was encountered.
WeakLazyAlias Internal
A specific internal error condition was detected in OPTLINK. If you
get this error, please contact Digital Mars Technical Support.
Fatal Error Messages
The following errors prevent a successful completion of OPTLINK,
processing stops immediately upon detection. An executable or
possibly a partial executable may have been created. This file is
unusable and should be deleted.
.DEF Syntax Error
An invalid .def file syntax could not be parsed.
.RES File Corrupt
The compiled resource (.res) file was found to be corrupt. To
correct it, rebuild the file using the rc.exe resource compiler and
its /r option switch.
APPLOAD Must Appear Before Any Segments
A segment precedes the APPLOADER directive in a .def file.
Bad FIXUPP Thread
A FIXUPP thread was referenced prior to being defined. The .obj
file is corrupt and must be regenerated. This condition can only be
caused by a translator error.
Bad LOC Frame in Start Address
An undefined FIXUPP frame was referenced in a start address. The
object file is corrupt and must be regenerated. This condition can
only be caused by a translator error.
Bad OMF Extension
The format of a type A0 COMENT record cannot be recognized.
Bad STUB File
An error was detected while parsing the specified STUB file.
Indicates an invalid DOS .exe file.
Cannot Create File
A requested output file cannot be created. Most probable causes are
the requested file name contains an invalid character, or the output
disk directory is full (applicable only to root directories).
Cannot parse Class record
Corrupt debug information.
Cannot Reopen Output File
A file access error was encountered, probably due to a sharing
violation on the output file.
Circular ALIAS
A chain of aliases references itself.
Colon Expected
An OPTLINK option that requires a number is requested, and the ":"
or following number is not given. Try the operation again, being
sure to supply all required numbers.
Dictionary Exceeded 512k
Library dictionaries have a size limit of 512Kb, which is unlikely to
ever be reached unless the /IMPLIB switch is used incorrectly.
Disk Full Writing
OPTLINK failed to find enough space on the disk to write the
required output (or virtual memory) file.
DOS Critical Error
DOS detects a "critical error" while processing a read or write
function for OPTLINK.
DOSSETFILEINFO Error
An OS/2 critical error occurred.
EMS Error
OPTLINK was notified of an EMS error while attempting to access
expanded memory. The only known causes for this error are faults
in either the EMS driver or the EMS hardware.
EXPORTed Names Text >64k
The exported names text exceeds the limit. Try using the /NONAMES
link option.
Filename Expected
OPTLINK failed to encounter a required file name as input.
File Not Found
Commands were given to perform an operation with a object file
which cannot be found.
Illegal Filename
A file name cannot be parsed into a valid format.
Illegal Record Syntax
OPTLINK was unable to decipher the syntax of a record in an object
file. The most likely cause is that the object file is corrupt, due either
to a disk accident or to a translator error.
/IMPLIB Needs Larger /PAGESIZE
Set the /PAGESIZE link option to a larger number.
Incremental Compile Error
A record was detected that says the .obj file being processed is
corrupt. Compilers such as Microsoft Quick C may create such
records upon detecting certain errors during an incremental compile.
Index Range
A record in the object file provides an index value which is outside
the allowable range of values. The most likely cause is that the
object file is corrupt, due either to a disk accident or to a translator
error.
Indirect File Nested Too Deep
The nesting level for indirect files exceeds 10.
Limit of 65535 Base FIXUPPs Exceeded
Attempted to created more than 65,535 relocation entries for a real-mode
executable. This limit is imposed by the structure of the .exe
file.
Module or Dictionary Corrupt
When attempting to read a .obj or .lib module, the first record
was invalid. This error can be caused by passing some other file
mistakenly as a .obj or .lib (syntax error). It also can be caused
by invalid library dictionaries built by incompatible tools.
Need Larger /ALIGNMENT Value
The segmented (Windows or OS/ 2) executable is larger than
64KB * ALIGNMENT. Alignment is the page boundary in the .exe or
.dll on which all segments will start. These segments are referred
to elsewhere by a 16-bit page number. OPTLINK defaults to an
ALIGNMENT of 16 (limits an executable to 1MB) to reduce wasted
space between segments, while other linkers normally waste space
by defaulting 512. To fix the problem, increase the ALIGNMENT size.
No Segments Linked!
No input files could be processed. Therefore, no file could be
created.
Not a Valid Library File
A .lib file fails to meet the criteria for .lib files.
Number Overflow
A number greater than 65,535 (16 bits) was supplied on the
command line.
OBJ Record Too Long
An object record exceeds 6000 bytes in length. The .obj or .lib
file is probably corrupt.
Out of Memory
OPTLINK does not have enough memory to continue operation.
OPTLINK needs to have a minimum of 200KB available. Try
removing a TSR or two, and link again, or (if you are using a
makefile) link from outside the MAKE program.
Overflow 32-bit Multiply
OPTLINK's far global data allocation routines encounter an address
value which they cannot successfully calculate. While it is
documented here for completeness, you are not likely to see this
message.
Selector Already Released
As a result of an internal processing error within OPTLINK. If you get
this error, please contact Digital Mars Technical Support.
Swap File Full
Virtual memory is exhausted. Delete any unnecessary files from your
disk and try again.
Token Too Long
A symbol name or other token exceeds the 468-character limit. The
.obj or .lib file is probably corrupt. The too-long symbol is
appended to the message.
Too Many Relocs to EXEPACK
More than 8,191 segment relocations per 64KB of data were involved
while performing EXEPACK on real-mode executable.
Too Many Segments For Segmented .EXE Format
The segmented .exe format can hold only 254 segments. Number
of segments has been exceeded, even after /PACKCODE and
/PACKDATA have been used. Try using .dll's to contain some
segments and thus reduce the size of this module.
Too Much EXESTR Data
More than one megabyte of EXESTR data (created by a MSC6. 0
pragma) exists. OPTLINK supports up to one megabyte of EXESTR
data.
Unexpected End of File
OPTLINK encountered the end of an input file before finding a
MODEND record. The most likely cause is that the object file is
corrupt, due either to a disk accident or to a translator bug.
Unknown FIXUPP Frame Type
OPTLINK was unable to determine the frame type of a FIXUPP
record in an object module. Most likely cause is that the object file
has been corrupted, or that a translator error has occurred.
Unrecognized B2 Record
OPTLINK found a type B2 record in its input files and was unable to
determine the meaning of the record. Most likely cause is that the
translator has added an undocumented extension to the B2 record
usage.
Unrecognized Communal Syntax
OPTLINK detected an error while processing a type B0 (Communal
Data) record.
Unrecognized Record
OPTLINK cannot recognize the type of a record in an object file.
User ABORT
The user pressed Control-C or Control-Break to abort the link
operation.
XMS Error
OPTLINK was notified of an XMS error while attempting to access
extended memory. The only known causes for this error are faults in
the XMS driver.
Copyright © 1995-2001 Digital Mars. All Rights Reserved.