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
eld Input and Output
eld Manual—527255-009
2-2
Target Platforms
•
Text files in Guardian subdirectories of OSS are code 180 files, not edit files.
When the linker creates a text file in a Guardian subvolume of OSS it is a code
180 file. When the linker reads a text file in a Guardian subvolume of OSS,
code 180 files always work, and edit files do not necessarily work.
•
OSS has the concept of a “file mode” used to control UNIX file security and
access rules. This file mode does not apply to files in the Guardian
namespace.
Target Platforms
The loadfiles created by the TNS/E linker can only be loaded and run on the TNS/E
versions of the HP NonStop operating system. A process can be run in either one of
two environments “Guardian” and “OSS”, dependent on it’s process ID.
The -set systype option specifies the target environment for the loadfile being built
by the TNS/E linker. The systype attribute has no meaning for a DLL. A DLL may be
usable by a Guardian process, or an OSS process, or both, depending on how the
various parts of it were written and compiled. However, you must be aware of how the
different parts were written and compiled to use it appropriately. The target
environment does not affect anything else the linker does unless otherwise specified in
this document. The target environment is indicated within the loadfile by the
EF_TANDEM_SYSTYPE bit in the e_flags field of the ELF header.
The default target environment is guardian for the linker hosted on Guardian. The
default is oss on the PC. The default on OSS is either guardian or oss, depending
on whether the object file is being created in a Guardian subvolume.
Filenames and The File Identifier
In the Guardian environment, “filename” is defined as the complete descriptor
(pathname) of \NODE.$VOL.SUBVOL.FILEID. The actual file’s name is contained in
the FILEID, the file identifier.
In the OSS environment, filename id defined as any component of the pathname, that
is /filename/filename/filename. The actual file’s name or file identifier comes after the
rightmost slash.
Sometimes the linker is required to put or pull off the file identifier of a filename, and
that means the following:
•
On Guardian, it is the part of the filename after the last period. If there is no
period in a name, the entire name is used.
•
On OSS, it is the part of the filename after the last slash, if any.
•
On the PC, it is the part of the filename after the last slash, backslash, or colon,
if any.










