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-85
Error Messages
have also given the -dll and -make_implicit_dll options, to tell eld to make one of
the implicit DLLs that constitute system library. System library is not allowed to contain
globalized symbols.
Effect. Fatal error (eld immediately stops without creating an output file).
Recovery. Assuming you do want to make an implicit DLL, you probably need to look
over your C++ source code to figure out why it has globalized symbols in it, and
change the code to avoid that. It is beyond the scope of this manual to explain the
rules that the C++ compiler uses in deciding which globalized symbols to create.
Cause. The C++ compiler marks some symbols as “globalized” symbols, because the
fixups to such symbols need to follow special rules at runtime. Each of the two files
mentioned in the message contain symbols of the same name, as shown in the
message. One of the copies was globalized and one wasn’t, which is an error. It
doesn’t matter if the declarations of the symbols are definitions or just external
references, they still need to agree on whether the symbol is globalized.
Effect. Fatal error (eld immediately stops without creating an output file).
Recovery. Did you really intend to define symbols with the same name in each of
these two files, and have both symbols visible across separate compilations? If not,
change the name of one of them, or change the declaration of one of them so that it is
defined and only visible within its own compilation. If you are using the same symbol in
more than one place, all the places must agree on whether that symbol is globalized.
If the symbols disagree about this because the two files were created from different
versions of the source code, or by using different compiler options, repeat the
compilations doing things more consistently.
Cause. You specified the -alf option, telling the name of the DLL that you want to
update, and this was one of the implicit DLLs that constitute system library. Various
other options are allowed with the -alf option, and some of these other options also
have filenames as parameters. But, in addition to all these filenames, you also had
another filename on the command line by itself, not as the parameter of an option. In
general, with the -alf option, it is possible to have one such filename, to tell the
name of the zimpimp file that represents the DLLs that constitute system library.
However, it is not possible to specify a zimpimp file when in fact you are now working
on one of the implicit DLLs themselves.
1535 Copies of symbol <symbol name>, in <filename> and
<filename>, don't agree on whether it is globalized.
1536 Filename <filename> was specified on the command line
with the -alf option, but that means that this file would be
the zimpimp file, and the existing file <filename> is an
implicit DLL, and an implicit DLL cannot use a zimpimp file,
so this is an error.










