2.9. Shared libraries in a development environment

When an application is started, the system loader reads the loader section of the header of the executable file. It reads the dependency information for any shared objects the executable requires and attempts to load the code for those shared objects into the system shared library segment if they are not already loaded. Shared objects that are loaded into the system shared library segment have an attribute called the use count. Each time an application program that uses the shared object is started, the use count is incremented. When an application terminates, the use count for any shared objects it was using is decreased by one. When the use count for a shared object in the system shared library segment reaches zero, the shared object is not unloaded, but instead remains in memory. This reduces the overhead of starting any applications that use the shared object since they will not have to load the object into the system shared segment again.

To relinquish the unused shared objects or library archive members residing in the system memory, you need to either explicitly call the slibclean command (requires root authority on the system) or remove the shared objects or libraries using the rm command.

However, this default behavior of shared objects and libraries on AIX can be difficult to control, especially in the development environment where shared objects or libraries can be constantly changed and altered so that new versions should be used. Furthermore, multiple application developers might be working with their own version of a single shared library in a large development environment.

In order to effectively manage shared objects and libraries in the development environment, there are several methods, including the following:

• Use the -L and -l linker options and the LIBPATH environment variable.

• Use private shared objects and libraries.

2.9.1. Production and development environments

If your application development directory structure does not match the directory structure used when your application is installed in a production environment, then, potentially, you need to adjust the arguments used with the linker to ensure that the resulting executables have the desired library search path.

When the application is installed in a production environment, for example, after being installed on the production system, the directory structure may be different. The method to use when compiling the executables will depend on the degree of freedom the customer is permitted when installing the application. For example, some applications expect that the executables and libraries must be installed in a specific directory, such as /opt/productname. Some applications allow the binaries and libraries to be installed in any directory structure.

• If the libraries for the application need to be installed in a specific directory, then you can either:

  - Create the shared libraries and then copy them to the same directory structure to be used when the product is installed in a production environment. In this case, use the -L option to specify the directory where the linker looks for shared objects and libraries. For example:

  cc -o ../bin/app1 main.c -llibone -L/product/lib
  

  - Create the shared libraries, but leave them in the development directory structure. When compiling the applications, use absolute pathnames to specify the shared libraries along with the -bnoipath linker option to prevent the pathname being included in the header section of the final executable. At the same time, use the -L option to specify the directory where the libraries will exist on a production system. For example:

  cc -o ../bin/app1 main.c -bnoipath ../lib/libone.a -L/product/lib
  

  Note

  In either case, all dependent shared objects and libraries should be installed in /product/lib (or /usr/lib, /lib) on the production system.

  
  

• If your application allows the executables and libraries to be installed in any directory structure, then the LIBPATH environment variable must be used accordingly on the production system to look for the dependent shared objects and libraries.

2.9.2. Private shared objects

When used under normal circumstances, a shared object is loaded into the system global shared object segment. Subsequent executables that use the shared object benefit from the fact that it is already loaded.

In a development environment, particularly on a system with multiple developers, it may be preferable to use a private copy of a shared object. This may be useful when developing and testing new functionality in a shared object that is specific to a particular version of the application that a single developer is working on.

If the shared object or library has the access permissions modified as detailed below, then when the system loader starts an application that uses this shared object, the shared object text will be loaded into the process private segment rather than the system shared object segment. The shared object data will also be loaded into the process private segment instead of its normal location of the process shared object data segment. This means every application that uses private shared objects and libraries will have its own private copy of the shared object text and data while sacrificing the smaller size of a process private data segment.

When the program exits, all private shared objects required by the program will be released from the memory.

To use a private copy of the shared text and data, modify the access permissions as follows:

• Remove the read permission for other of the shared object as follows:

  chmod o-r foo.o
  

• Remove the read permission for other of the shared library as follows:

  chmod o-r libfoo.a
  

2.9.3. NFS consideration

Often, an application runs on NFS clients, whereas the actual executable file for the application and referenced shared objects or libraries stored on the NFS server. AIX tries to maintain the reliability of the running process by copying modules to the NFS client’s paging space.

Although the likelihood of a shared module changing from a running process is minimal, this behavior avoids the potential of a process abend due to an NFS client and server losing synchronization in their respective understandings of the contents of a particular file. If a shared object referenced by the application is updated on the NFS server, and the inode does not change, then the kernel believes that the existing copy is current, and therefore will not pick up the new file. In this case, the slibclean command must be executed on the NFS client to pick up the new module on the NFS server. This is only effective if the module in question is no longer in use by any running process on the client.

2.9.4. Sufficient free disk space on the target directory and /tmp

The linker ^[19] maps the output file into its shared memory segment using shmat() (see “Mapping files with shmat()” on page 144 for detailed information about the shmat() services). The pages are flushed to disk when the linker exits. If the output file is on a remote file system, or on a file system that does not support mapping, a temporary file is created locally, which is then copied to the remote file system. The temporary file will be created in the directory defined by the TMPDIR environment value, or in /tmp, if TMPDIR is not defined. Therefore, it is recommended to have enough free disk space on the target directory and /tmp in a development environment for this action.

^[19] The linker, Id, is a 32-bit program.