eld Manual
Table Of Contents
- eld Manual
- Legal Notices
- Contents
- What’s New in This Manual
- Manual Information
- New and Changed Information
- About This Manual
- Notation Conventions
- 1 Introduction to eld
- 2 eld Input and Output
- 3 Binding of References
- Overview
- Presetting Loadfiles
- To Preset or Not to Preset, and Creation of the LIC
- Handling Unresolved References
- Using User Libraries
- Creating Import Libraries
- Ignoring Optional Libraries
- Merging Symbols Found in Input Linkfiles
- Accepting Multiply-Defined Symbols
- Using the -cross_dll_cleanup option
- Specifying Which Symbols to Export, and Creating the Export Digest
- Public Libraries and DLLs
- The Public Library Registry
- 4 Other eld Processing
- Adjusting Loadfiles: The -alf Option
- Additional rules about -alf
- The -set and -change Options
- eld Functionality for 64-Bit
- Checking the C++ Language Dialect
- Renaming Symbols
- Creating Linker-Defined Symbols
- Updating Or Stripping DWARF Symbol Table Information
- Modifying the Data Sections that Contain Stack Unwinding Information
- Creating the MCB
- Processing of Floating Point Versions and Data Models
- Specification of the Main Entry Point
- Specifying Runtime Search Path Information for DLLs
- Merging Source RTDUs
- 5 Summary of Linker Options
- 6 Output Listings and Error Handling
- A TNS/E Native Object Files
- Glossary
- Index

Output Listings and Error Handling
eld Manual—527255-009
6-25
Error Messages
Recovery. In special cases, different loadfiles within the same process may be able to
use different dialects of C++. You may wish to check with someone who is familiar with
the DLL mentioned in the message, to see if there might be problems at runtime due to
this dialect inconsistency.
Cause. The input files use the v3 dialect of C++, and during the link eld saw a DLL
that was using the v2 dialect of C++.
Effect. Warning (eld produces an output file, but it might not be what you intended).
Recovery. In special cases, different loadfiles within the same process may be able to
use different dialects of C++. You may wish to check with someone who is familiar with
the DLL mentioned in the message, to see if there might be problems at runtime due to
this dialect inconsistency.
Cause. Before eld creates an output file, it first writes to a temporary workfile that is
in the same location (Guardian subvolume, OSS directory, or PC folder) as the final file
to be created. eld chooses a filename for the workfile of a certain pattern, as shown
in the message, where three of the characters will be filled in with a number from 000
to 999. eld was not able to create any file whose name matched this pattern, perhaps
because 1000 files with names matching the pattern already existed. They might exist
because previous runs of eld failed and left these files behind. eld doesn’t delete
such files that previously existed, it only tries to find an unused name.
Effect. Fatal error (eld immediately stops without creating an output file).
Recovery. Check that you have permission to create files in the indicated location,
and that it isn’t a Guardian subvolume that is full, and also see whether there already
are 1000 files in existence, with names matching the pattern. If so, delete some of
them.
Cause. Based on the options you specified, you are trying to use eld to create a new
object file from a set of existing object files. However, no existing object files were
specified on the command line, to be included in the output file. Perhaps you specified
DLLs on the command line, but DLLs are only referenced during the link, not included
in the output file. Perhaps you specified archives on the command line, but the object
files within an archive are only included in the link if the -all option is in effect, or if a
previous object file already in the link refers to a symbol that an archive member can
provide.
1153 The loadfile being built has C++ dialect v3; DLL
<filename> has C++ dialect v2.
1155 Could not create workfile of the form <string>.
1156 No input files.










