Use the ld link-editor to link to object files. ld is a cross link-editor that can link 32-bit objects or 64-bit objects for SPARC or x86 systems. ld uses the ELF class on system type of the first relocatable object on the command line to govern the mode in which to operate. If the linker is presented with a collection of ELF32 object files as input, it creates an ELF32 output file; similarly, if it is presented with a collection of ELF64 object files as input, it creates an ELF64 output file. Attempts to mix ELF32 and ELF64 input files are rejected by the linker.
The following table lists the dynamic linkers for SPARC and x86 platforms:
|
For more information, see the ld(1) man page.
At runtime, both dynamic linkers search the same list of colon-separated directories specified by the LD_LIBRARY_PATH environment variable. However, the 32-bit dynamic linker binds only to 32-bit libraries, while the 64-bit dynamic linker binds only to 64-bit libraries. So directories containing both 32-bit and 64-bit libraries can be specified via LD_LIBRARY_PATH, if needed.
The 64-bit dynamic linker's search path can be overridden by using the LD_LIBRARY_PATH_64 environment variable and 32-bit dynamic linker search path can be overridden by using the LD_LIBRARY_PATH_32 environment variable.
A common technique for distributing and managing applications is to place related applications and libraries in a directory hierarchy. Typically, the libraries used by the applications reside in a lib subdirectory, while the applications themselves reside in a bin subdirectory of a base directory. This base directory can then be exported by using NFS and mounted on client systems. In some environments, the automounter and the name service can be used to distribute the applications, and to ensure the file system namespace of the application hierarchy is the same on all clients. In such environments, the applications can be built by using the –R flag to the linker to specify the absolute path names of the directories that should be searched for shared libraries at runtime.
However, in other environments, the file system namespace is not so well controlled, and developers have resorted to using a debugging tool – the LD_LIBRARY_PATH environment variable – to specify the library search path in a wrapper script. This is unnecessary, because the $ORIGIN keyword can be used in path names specified to the linker –R option. The $ORIGIN keyword is expanded at runtime to be the name of the directory where the executable itself is located. This effectively means that the path name to the library directory can be specified by using the pathname relative to $ORIGIN. This allows the application base directory to be relocated without having to set LD_LIBRARY_PATH at all.
This functionality is available for both 32-bit and 64-bit applications, and it is well worth considering when creating new applications to reduce the dependencies on users or scripts correctly configuring LD_LIBRARY_PATH.
For more information, see Oracle Solaris 11.3 Linkers and Libraries Guide.