|Skip Navigation Links|
|Exit Print View|
|Linker and Libraries Guide Oracle Solaris 11 Information Library|
The link-editor can create stub objects. Stub objects are shared objects, built entirely from mapfiles, that supply the same linking interface as the real object while containing no code or data. Stub objects can be built very quickly by the link-editor, and can be used to increase build parallelism and to reduce build complexity. See Stub Objects.
The link-editor can provide guidance in creating high quality objects using the -z guidance option. See ld(1).
Archive processing now allows the creation of archives greater than 4 Gbytes in size.
Local auditors can now receive la_preinit() and la_activity() events. See Runtime Linker Auditing Interface.
A new mapfile syntax is provided. See Chapter 10, Mapfiles. This syntax provides a more human readable, and extensible language than the original System V Release 4 language. Full support for processing original mapfiles is maintained within the link-editor. See Appendix B, System V Release 4 (Version 1) Mapfiles for the original mapfile syntax and use.
Individual symbols can be associated with capability requirements. See Identifying Capability Requirements. This functionality provides for the creation of a family of optimized functions within a dynamic object. See Creating a Family of Symbol Capabilities Functions, and Capabilities Section.
Objects that are created with the link-editor, and contain Oracle Solaris specific ELF data, are tagged with ELFOSABI_SOLARIS in the e_ident[EI_OSABI] ELF header. Historically, ELFOSABI_NONE has been used for all objects. This change is primarily of informational value, as the runtime linker continues to consider ELFOSABI_NONE and ELFOSABI_SOLARIS to be equivalent. However, elfdump(1), and similar diagnostic tools, can use this ABI information to produce more accurate information for a given object.
elfdump(1) has been extended to use the value of e_ident[EI_OSABI] ELF header, or the new -O option, to identify ELF data types and values that are specific to a given ABI, and to use this information to provide a more accurate display of the object contents. The ability to display ABI-specific information in objects from the Linux operating system has been greatly expanded.
The segment mapping information for an object that is loaded with a process can be obtained using the dlinfo(3C) flags RTLD_DI_MMAPCNT and RTLD_DI_MMAPS.
The link-editor recognizes a number of GNU link-editor options. See ld(1).
The link-editor provides cross linking for SPARC and x86 targets. See Cross Link-Editing.
The link-editor now provides for merging SHF_MERGE | SHF_STRING string sections. See Section Merging.
The merging of relocation sections when creating executables and shared objects is now the default behavior. See Combined Relocation Sections. This behavior used to require the link-editor's -z combreloc option. The -z nocombreloc is provided to disable this default behavior, and preserve the one-to-one relationship with the sections to which the relocations must be applied.
ELF objects can be edited with the new utility elfedit(1).
Arbitrary data files can be encapsulated within ELF relocatable objects using the new utility elfwrap(1).
The link-editor, and associated ELF utilities have been moved from /usr/ccs/bin to /usr/bin. See Invoking the Link-Editor.
Symbol sort sections have been added, that allow for simplified correlation of memory addresses to symbolic names. See Symbol Sort Sections.
The format of configuration files that are managed with crle(1) has been enhanced for better file identification. The improved format ensures that the runtime linker does not use a configuration file generated on an incompatible platform.
New relocation types have been added that use the size of the associated symbol in the relocation calculation. See SPARC: Relocations.
The -z rescan-now, -z recan-start, and -z rescan-end options provide additional flexibility in specifying archive libraries to a link-edit. See Position of an Archive on the Command Line.
The following items have been made obsolete. These items provided internal, or seldom used features. Any existing use of the associated ELF definitions is ignored, however the definitions can still be displayed by tools such as elfdump(1).
This dynamic section tag identified runtime feature requirements. See Dynamic Section. This tag provided the feature flags DTF_1_PARINIT and DTF_1_CONVEXP. The DT_FEATURE_1 tag and the associated flags are no longer created by the link-editor, or processed by the runtime linker.