JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris 11.1 Linkers and Libraries Guide     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information


Part I Using the Link-Editor and Runtime Linker

1.  Introduction to the Oracle Solaris Link Editors

2.  Link-Editor

Invoking the Link-Editor

Direct Invocation

Using a Compiler Driver

Cross Link-Editing

Specifying the Link-Editor Options

Input File Processing

Archive Processing

Shared Object Processing

Linking With Additional Libraries

Library Naming Conventions

Linking With a Mix of Shared Objects and Archives

Position of an Archive on the Command Line

Directories Searched by the Link-Editor

Directories Searched by the Runtime Linker

Initialization and Termination Sections

Symbol Processing

Symbol Visibility

Symbol Resolution

Simple Resolutions

Complex Resolutions

Fatal Resolutions

Undefined Symbols

Generating an Executable Output File

Generating a Shared Object Output File

Weak Symbols

Tentative Symbol Order Within the Output File

Defining Additional Symbols

Defining Additional Symbols with the -u option

Defining Symbol References

Defining Absolute Symbols

Defining Tentative Symbols

Augmenting a Symbol Definition

Reducing Symbol Scope

Symbol Elimination

External Bindings

String Table Compression

Generating the Output File

Identifying Capability Requirements

Identifying a Platform Capability

Identifying a Machine Capability

Identifying Hardware Capabilities

Identifying Software Capabilities

Creating a Family of Symbol Capabilities Functions

Creating a Family of Symbol Capabilities Data Items

Converting Object Capabilities to Symbol Capabilities

Exercising a Capability Family

Relocation Processing

Displacement Relocations

Stub Objects

Ancillary Objects

Debugger Access and Use of Ancillary Objects

Parent Objects

Debugging Aids

3.  Runtime Linker

4.  Shared Objects

Part II Quick Reference

5.  Link-Editor Quick Reference

Part III Advanced Topics

6.  Direct Bindings

7.  Building Objects to Optimize System Performance

8.  Mapfiles

9.  Interfaces and Versioning

10.  Establishing Dependencies with Dynamic String Tokens

11.  Extensibility Mechanisms

Part IV ELF Application Binary Interface

12.  Object File Format

13.  Program Loading and Dynamic Linking

14.  Thread-Local Storage

Part V Appendices

A.  Linker and Libraries Updates and New Features

B.  System V Release 4 (Version 1) Mapfiles


Parent Objects

Programs that offer extensible functionality often make use of shared objects, loaded at runtime using the dlopen() function. These shared objects are often referred to as plugins, and provide a flexible means to extend the abilities of the core system. The object that loads the plugins is referred to as the parent.

A parent object loads the plugin and accesses functions and data from within the plugin. It is also common for the parent object to provide functions and data for use by the plugin. This is illustrated by the following parent and plugin source files. Here the parent supplies a function named parent_callback() for the benefit of the plugin. The plugin supplies a function named plugin_func() for the parent to call.

$ cat main.c
#include <stdio.h>
#include <dlfcn.h>
#include <link.h>

        (void) printf("plugin_func() has called parent_callback()\n");

main(int argc, char **argv)
        typedef void plugin_func_t(void);

        void            *hdl;
        plugin_func_t   *plugin_func;

        if (argc != 2) {
                (void) fprintf(stderr, "usage: main plugin\n");
                return (1);

        if ((hdl = dlopen(argv[1], RTLD_LAZY)) == NULL) {
                (void) fprintf(stderr, "unable to load plugin: %s\n", dlerror());
                return (1);

        plugin_func = (plugin_func_t *) dlsym(hdl, "plugin_func");
        if (plugin_func == NULL) {
                (void) fprintf(stderr, "unable to find plugin_func: %s\n",
                return (1);


        return (0);

$ cat plugin.c
#include <stdio.h>
extern    void    parent_callback(void);
    (void) printf("parent has called plugin_func() from\n");

$ cc -o main main.c -lc
$ cc -Kpic -G -o plugin.c -lc
$ ./main ./
parent has called plugin_func() from
plugin_func() has called parent_callback()

When building any shared object, the -z defs option is recommended, in order to ensure that the object specifies all of its dependencies. However, the use of -z defs prevents the plugin object from linking due to the unsatisfied symbol from the parent object.

$ cc -zdefs -Kpic -G -o plugin.c -lc
Undefined                       first referenced
 symbol                             in file
parent_callback                     plugin.o
ld: fatal: symbol referencing errors. No output written to

A mapfile can be used to specify to the link-edit that the parent_callback() symbol is supplied by the parent object.

$ cat plugin.mapfile
$mapfile_version 2

        parent_callback         { FLAGS = PARENT };
$ cc -zdefs -Mplugin.mapfile -Kpic -G -o plugin.c -lc

The preferred solution for building a plugin is to use the -z parent option to provide the plugin with direct access to symbols from the parent. An added benefit of using -z parent instead of a mapfile, is that the name of the parent object is recorded in the dynamic section of the plugin, and is displayed by the file utility.

$ cc -zdefs -zparent=main -Kpic -G -o plugin.c -lc
$ elfdump -d | grep PARENT
       [0]  SUNW_PARENT       0xcc                main
$ file ELF 32-bit LSB dynamic lib 80386 Version 1,
           parent main, dynamically linked, not stripped