Section 5.5. Linker

5.5. Linker

Like UNIX, AIX and Linux provide facilities for the creation, development, testing, and debugging of shared libraries and applications that use them. AIX linker utilizes the eXtensible Common Object File Format (XCOFF), and Linux utilizes the Executable and Linkable Format (ELF). Early versions of Linux used a version of the old "a.out" format, but that format had many limitations that ELF corrects. ELF has become the most popular binary file format for UNIX and related operating systems such as Linux.

On both platforms, the default name for an XCOFF and ELF executable file is a.out.

5.5.1. Linker Incompatibilities

Although both AIX and Linux view "static linking" as the technique of defining multiple object files defining global symbols, and containing code and data, which are combined and written to an executable file with all references defined, they have different views on how the linker handles libraries in general. The linker and loader on AIX are designed such that libraries are self-contained entities with well-defined interfaces consisting of sets of imported and exported symbols. The system loader looks up symbols to relocate references, but all symbol resolution is performed at link time, simplifying the work of the loader. Shared objects in AIX are considered fully linked and resolved entities, where symbol references are resolved at link time and cannot be rebound at load time. On the other hand, Linux utilizes a version of linking, whereas it sees libraries as being very similar to ordinary ELF files where resolution of all global symbols is performed at runtime by the loader. In Linux, a dynamically linked file contains a Procedure Linkage Table (PLT). This table contains all the linker information that the runtime linker needs to relocate files and resolve any undefined symbols. The segment within the PLT that the loader examines when it loads a dynamically linked file is the DYNAMIC section. The DYNAMIC section contains the tagged values and pointers that the loader needs to locate symbols.

A shared module in AIX can be an object file or an archive file member, which can contain shared modules and/or ordinary object files. In Linux, shared libraries are always ordinary ELF object files, created with special options. Because of these differences, on the AIX platform GNU utilizes the native AIX linker rather than the GNU linker to link GNU executables.

In AIX to enable runtime linking (RTL), you must specify the brtl parameter on the link line when building shared objects. The equivalent parameter in Linux is the shared parameter. Both simply tell the loader to defer resolution of certain identified symbols until runtime. On AIX, when used with bdynamic, brtl also changes the search behavior for libraries on the link line. When both switches are turned on in AIX, the l parameter tells the linker to search for libraries with .so and .a extensions (that is, shared objects and archives with precedence on .so). This is why archives can contain shared objects as members in AIX. In Linux, the ld command utilizes the standard UNIX behavior for searching for libraries, and the l parameter only searches for archives (.a). For example, in Linux the following ld command searches for a libout.a library:

ld o output lout L/usr/libs 

The following command builds an RTL shared object in Linux:

ld shared o libshobj.so lout L/usr/libs 

Additionally, Linux and AIX handle symbol resolution differently. In AIX, when the linker is resolving symbols, it grabs all the code available from the archive whether it needs it or not. In Linux, the linker only grabs what it needs. The downside is in Linux you may have to list archives on the command line more than once (unlike with AIX, in which you only need to list them once). This forces the Linux linker to search the archive more than once for additional symbols found in subsequent object files that are listed further down the link line.

As you can see, if you are accustomed to the AIX linker and loader mechanism for building archives and shared objects, you will have to make a few changes in your build environment before building on the Linux platform. Additional differences that AIX users need to be mindful of when porting to Linux include the following:

• In AIX, because archives can contain shared modules and vice versa, for archives that contain both shared objects and regular archives, the shared objects have to be separated from the link line (ld command) and built as separate linkable shared objects with .so extensions. The same goes for .o (object) files that contain shared objects.

• Shared objects that are passed to the Linux linker via the l parameter have to be moved further down the link line (ld command) after the object file listing with the fully named shared library specified (for example, libshobj.so).

• To resolve symbols, archives may have to be listed more than once on the link line down level from triggering modules.

5.5.2. Linker: AIX to Linux Reference

Although GNU linker (ld) has a plethora of parameters, when porting from AIX you only have to concern yourself with a few. Table 5-4 highlights some subtle differences in the most commonly used parameters that are somewhat necessary, depending on your target, when porting to Linux from AIX.

Table 5-4. AIX and Linux Linker Switches Comparison Table^[*]

AIX	Linux	Description
-bexpall	-E --export-dynamic	When creating a dynamically linked executable, adds all symbols to the dynamic symbol table.
-bmaxdata:<size>	-Gvalue --gpsize=value	Sets the maximum size of objects to be optimized using the GP register to size. This is only meaningful for object file formats such as MIPS ECOFF that support putting large and small objects into different sections. This is ignored for other object file formats.
-eLabel	-eenTRy --enTRy=entry	Uses enTRy as the explicit symbol for beginning execution of your program, rather than the default entry point.
-bdynamic or bshared	-Bdynamic -dy -call_shared or -Wl brt -shared	Links against dynamic libraries. The different variants of this option are for compatibility with various systems. You may use this option multiple times on the command line: It affects library searching for -l options that follow it.
-bM:SRE or brtl or G	-shared -Bshareable	Creates a shared library that is reentrant (runtime linkable).
-l	-larchive	Adds archive file libarchive.a to the list of files to link. This option may be used any number of times. This option also searches for shared objects (.so) for other platforms; however, when running on a Linux platform, only archives are searched.
-Z	-Y	Specifies a search path for library names.
-L	-rpath path	Specifies the library search direction for the runtime linker.
-L	-L	Searches the specified directory for library files specified by the -l option.

^[*] Caution is advised when using the equivalent Linux solutions presented. The list is presented only as a reference and not as officially recommended solutions. Please investigate the viability of the solutions before planning to implement them in your applications.

The GNU linker (ld) is meant to cover a broad range of situations and to be as compatible as possible with other linkers. As a result, you have many other choices to control its behavior. But if you want your application to remain portable, you can use the GNU libtool for building libraries for Linux. GNU libtool is a generic library support script that hides the complexity of using libraries (for example, creating and installing shared and archived libraries) behind a consistent, portable interface. On Linux, GNU libtool is built on top of the tools and conventions for using the standard GNU Library (glib). Refer to the GNU libtool online for additional options and its usage.