The following compile line creates the executable yourApp by linking with the DSOs libyours.so and with libc.so.1:

cc yourApp.c -o yourApp -lyours

If libyours.so isn't available, but the archive version libyours.a is available, that archive version is used along with libc.so.1.

You should note that a significant difference exists between DSOs and archive libraries in terms of what gets loaded into memory when an application is executing. With an archive library, only the text portion of the library that the application actually requires (and the data associated with that text) gets loaded, not the entire library. In contrast, the entire DSO that's linked gets loaded. Thus, to conserve memory, don't link with DSOs unless your application actually needs them.

Also, you should avoid listing any archive libraries on the compile line after you list shared libraries; instead, list the archive libraries first and then list the DSOs.

You may want to take advantage of the QuickStart optimization that minimizes start-up times for executables. You can use QuickStart when using or building DSOs. At link time, when an executable or a DSO is being created, the linker ld assigns initial addresses to the object and attempts to resolve all references. Since DSOs are relocatable, these initial address assignments are really only guesses about where the object will be really loaded. At run time, rld verifies that the DSO being used is the same one that was linked with and what the real addresses are. If the DSOs are the same and if the addresses match the initial assignments, rld doesn't have to perform any relocation work, and the application starts up quickly (or QuickStarts). When an application QuickStarts, memory use is smaller since rld doesn't have to read in the information necessary to perform relocations.

To determine whether your application (or DSO) is able to do a QuickStart, use the –quickstart_info flag when building the executable (or DSO). If the application or DSO can't do a QuickStart, you'll be given information about how what to do. The next section goes into more detail about why an executable may not be able to use QuickStart.

In summary, when you use DSOs to build an executable:

When you're working with DSOs, you can avoid some common pitfalls if you adhere to the guidelines described in this section:

ld -shared -all mylib.a -o mylib.so -lfoo

#objects        #objects 
   ...   .          ...
   printf.o         trcmp.o
   fopen.o          malloc.o 
   malloc.o         printf.o
   strcmp.o         fopen.o
   ...  .           ...

To create a DSO from a set of object files, use ld with the –shared option:

ld –shared stuff.o nonsense.o –o libdada.so 

The above example creates a DSO, libdada.so, from two object files, stuff.o and nonsense.o. Note that DSO names should begin with "lib" and end with ".so", for ease of use with the compiler driver's –llib argument. If you're already building an archive library (.a file), you can create a DSO from the library by using the –shared and –all arguments to ld:

ld –shared –all libdada.a –o libdada.so

The –all argument specifies that all of the object files from the library, libdada.a, should be included in the DSO.

When building a DSO, be sure to include any archives required by the DSO on the link line so that the DSO is self-contained (that is, it has no unresolved symbols). If the DSO depends on libraries not explicitly named on the link line, subsequent changes to any of those libraries may result in name space collisions or other incompatibilities that can prevent any applications that use the DSO from doing a QuickStart. Such incompatibilities can also lead to unpredictable results over time as the libraries change asynchronously. To make the archive libmine.a into a DSO, for example, and libmine.a depends on routines in another archive, libutil.a, include libutil.a on the link line:

ld –shared –all -no_unresolved libmine.a –o libmine.so -none libutil.a

This causes the modules in libutil.a that are referenced in libmine.a to be included in the DSO, but these modules won't be exported. See "Controlling Symbols to be Exported or Loaded" for more information about exported symbols. The –no_unresolved option causes a list of unresolved symbols to be created; generally, this list should be empty to enable QuickStarting.

Similarly, if a DSO relies on another DSO, be sure to include that DSO on the link line. For example:

ld –shared –all -no_unresolved libbtree.a –o libtree.so –lyours

This example places libyours.so in the liblist of the new DSO, libtree.so. This ensures that libyours.so is loaded whenever an executable that uses libtree.so is launched. Again, symbols from libyours.so won't be exported for use by other libraries. (You can use the –exports flag to reverse this exporting behavior; the –hides flag specifies the default exporting behavior.)

By default, to help avoid conflicts, symbols defined in an archive or a DSO that's used to build another DSO aren't externally visible. You can explicitly export or hide symbols with the –exported_symbol and –hidden_symbol options:

-exported_symbol name1, name2, name3 
-hidden_symbol name4, name5

By default, if you explicitly export any symbols, all other symbols are hidden. If you both explicitly export and explicitly hide the same symbol on the link line, the first occurrence determines the behavior. You can also create a file of symbol names (delimited by white space) that you want explicitly exported or hidden, and then refer to the file on the link line with either the -exports_file or -hiddens_file option:

-exports_file yourFile 
-hiddens_file anotherFile

These files can be used in addition to explicitly naming symbols on the link line.

Another useful option, –delay_load, prevents a library from being loaded until it's actually referenced. Suppose, for example, that your DSO contains several functions that are likely to be used in only a few instances. Furthermore, those functions rely on another library (archive or DSO). If you specify –delay_load for this other library when you build your DSO, the run-time linker loads that library only when those few functions that require it are used. Note that if you explicitly export any symbols defined in a library that the run-time linker is supposed to delay loading, the export behavior takes precedence and the library is automatically loaded at run time.

---

Note: You can build DSOs using cc. However, if you want to export symbols/files or use –delay_load, use ld to build DSOs.

---

To make a DSO, build the C++ objects as you would normally:

CC -c

Then type:

CC -shared -o libmylib.so <list your objects here>

For example:

CC -shared -o libmylib.so a.o b.o c.o

In this instance, the –l and –L options to ld will work. However, most ld options won't work. If you want to specify other options, first determine the options that you must pass to ld. These options include:

-init _main
-fini _fini
-hidden_symbol _main
-hidden_symbol _fini
-hidden_symbol __head
-hidden_symbol __endlink

Finally, link in /usr/lib/c++init.o.

You can make sure that your DSOs don't conflict with each other by using a QuickStart registry file. The registry files contain location information for shared objects. When creating a shared object, you can specify a registry file to ld, and ld ensures that your shared object doesn't conflict with any of the shared objects listed in the registry. A registry file containing the locations of all the shared objects provided with the system is supplied in /usr/lib/so_locations.

You can use two options to ld to specify a registry file: –check_registry and –update_registry. When you invoke ld to build a shared object, with the argument –check_registryfile, ld makes sure that the new shared object doesn't conflict with any of the shared objects listed in file. When invoked with –update_registryfile, ld checks the registry in the same way, but when it's done, it writes an entry in file for the DSO being built. If file isn't writable, –update_registry acts like –check_registry. If file isn't readable, both –update_registry and –check_registry are ignored.

By exchanging registry files, providers of DSOs can avoid collisions between their shared objects. You should probably start out with a copy of /usr/lib/so_locations, so that your shared objects won't conflict with any of the standard DSOs. However, you should remember that when collisions occur between shared objects, the only effect is slowing program startup.

$text_align_size=align padding=pad-size
$data_align_size=align padding=pad-size

$start_address=addr

$data_after_text={ 1 | 0 }

so_name [ :st = {.text | .data | $range} base_addr,padded_size : ] *

libc.so.1 \
           :st = $range 0x5fc00000, 0x00400000:\
           :st = .text 0x5fe40000, 0x000a0000:\
           :st = .data 0x5fee0000, 0x00030000:

When you run a dynamically linked executable, the run-time linker, rld, identifies the DSOs required by the executable, loads the required DSOs, and if necessary relocates DSOs within the process's virtual address space, so that no two DSOs occupy the same location.The program header of a dynamically linked executable contains a field, the liblist, which lists the DSOs required by the executable.

When looking for a DSO, rld searches directories in the following sequence:

RPATH is a colon-separated list of directories stored in the main executable. You can set RPATH by using the –rpath argument to ld:

ld –o myprog myprog.c –rpath /d/src/mylib libmylib.so –lc

This example links the program against libmylib.so in the current directory, and configures the executable such that rld searches the directory /d/src/mylib when searching for DSOs.

The LD_LIBRARY_PATH environment variable is a colon-separated list of directories to search for DSOs. This can be very useful for testing new versions of DSOs before installing them in their final location. You can set the environment variable _RLD_ROOT to a colon-separated list of directories. The run-time linker prepends these to the paths in RPATH and the paths in the default search path.

In all of the colon-separated directory lists, an empty field is interpreted as the current directory. A leading or trailing colon counts as an empty field. Thus, if you set LD_LIBRARY_PATH to:

/d/src/lib1:/d/src/lib2:

The run-time linker searches the directory /d/src/lib1, then the directory /d/src/lib2, and then the current directory.

---

Note: For security reasons, if an executable has its set-user-ID or set-group-ID bits set, the run-time linker ignores the environment variables LD_LIBRARY_PATH and _RLD_ROOT. However, it still searches the directories in RPATH and the default path.

---

Dynamically linked executables can contain symbol references that aren't resolved before run time. Any symbol references in your main program or in an archive must be resolved at link time, unless you specify the –ignore_unresolved argument to cc. DSOs may contain references that aren't resolved at link time. All data symbols must be resolved at run time. If rld finds an unresolvable data symbol at run time, it will cause the executable to exit with an error. Text symbols are resolved only when they're used; so a program can run with unresolved text symbols, as long as the unresolved symbols aren't used.

You can force rld to resolve text symbols at run time by setting the environment variable LD_BIND_NOW. If unresolvable text symbols exist in your executable and LD_BIND_NOW is set, the executable will exit with an error, just as if there were unresolvable data symbols.

int foo[100];

COMMON i, j /* definition of i, j with initial values */
DATA i/1/, j/1/
call junk
end

COMMON i, j
/* definition of i, j with NO initial values */
/* initialized by kernel to all zeros */
print *, i, j
end

0 0

1

In the IRIX 5.0.1 release, a mechanism for the versioning of shared objects was introduced for SGI-specific shared objects and executables. Note that this mechanism is outside the scope of the ABI, and, thus, must not be relied on for code that must be ABI-compliant and run on non-SGI platforms. Currently, all executables produced on SGI systems are marked SGI_ONLY to allow use of the versioning mechanism.

Versioning is mainly of interest to developers of shared objects. It may not be of interest to you if you simply use shared objects. Versioning allows a developer to update a shared object in a way that may be incompatible with executables previously linked against the shared object. This is accomplished by renaming the original shared object and providing it along with the (incompatible) new version.

A version is part or all of an identifying version_string that can be associated with a shared object by using the – set_versionversion_string option to ld(1) when the shared object is created.

A version_string consists of one or more versions separated by colons (:). A single version has the form:

[comment#]sgimajor.minor

where:

Follow these instructions when building your shared library:

When you first build your shared library, give it an initial version, for example, sgi1.0. Add the option – set_version sgi1.0 to the command to build your shared library (cc – shared, ld – shared).

Whenever you make a compatible change to the shared object, create another version by changing the minor version number (for example, sgi1.1) and add it to the end of the version_string. The command to set the version of the shared library now looks like – set_version "sgi1.0:sgi1.1".

When you make an incompatible change to the shared object:

This versioning mechanism affects executables in the following ways:

For example, suppose you have a shared object foo.so with initial version sgi10.0. Over time, you make two compatible changes for foo.so that result in the following final version_string for foo.so:

initial_version#sgi10.0:upgrade#sgi10.1:new_devices#sgi10.2

You then link an executable that uses this shared object, useoldfoo. This executable specifies version sgi10.2 for sonamefoo.so. (Remember that the executable inherits the last version in the version_string of the shared object.)

The time comes to upgrade foo.so in an incompatible way. Note that the major version of foo.so is 10, so you move the existing foo.so to the file name foo.so.10 and create a new foo.so with the version_string:

efficient_interfaces#sgi11.0

New executables linked with foo.so use it directly. Older executables, like useoldfoo, attempt to use foo.so, but find that its version (sgi11.0) is not the version they need (sgi10.2). They then attempt to find a foo.so in the file name foo.so.10 with version sgi10.2.

---

Note: When a needed DSO has its interface changed, then a new version is created. If the interface change is not compatible with older versions, then a consuming shared object needs incompatible versions in order to use the new version, even if it doesn't use that part of the interface that is changed.

---