What are the differences between SO, O, lo, A, and La files in Linux?

O: compiled target file
A: static library, in fact, is to pack several o files
So: dynamic link library (Shared Library)

Lo: the target file compiled using libtool is actually added to the o file.
La: library files compiled using libtool are actually text files that record information about dynamic and static libraries with the same name
 
1. How libtool works
Libtool is a common library that supports scripts. It hides the complexity of dynamic libraries in a unified and portable interface. It uses the standard libtool method, you can create and call dynamic libraries on different platforms. It can be considered that libtool is an abstraction of GCC, which encapsulates GCC (or other compilers). You only need to tell libtool which libraries need to be compiled without knowing the details, libtool handles library dependencies and other details. Libtool only deals with libtool files with the suffix Lo and La.

Libtool is mainly used to solve the library dependency problem during compilation of large software. It takes over the maintenance of library dependency, and releases the human resources of programmers. Libtool provides a unified interface that hides the differences in the names of libraries on different platforms and generates an abstract extension named libxx from the LA high-level library. la (actually a text file), and write the dependencies between the library and other libraries in the La file. Dependency_libs in this file records all libraries that the library depends on (some of them are. in the form of a la file); libdir indicates the library installation location; library_names records the name of the Shared Library; old_library records the name of the static library.

When the compilation process reaches the link stage, if the following command is available:

$ Libtool -- mode = link GCC-O myprog-rpath/usr/lib-L/usr/lib-la

Libtool searches for LIBA in the/usr/lib path. then read the name of the actual shared library (this name is recorded in library_names, such as LIBA. so) and path (recorded in lib_dir, for example, libdir = '/usr/lib'), return such as/usr/lib/LIBA. so parameter to the GCC command line.

If LIBA. so depends on the Library/usr/lib/libb. so, then in LIBA. dependency_libs = '-L/usr/lib-lb' or dependency_libs ='/usr/lib/libb. la ', if it is the former, it will directly pass "-l/usr/lib-lb" as a parameter to the GCC command line; if it is the latter, libtool will be from/usr/lib/libb. read the actual libb from LA. so library name and path, and then combined into the parameter "/usr/lib/libb. so "is passed to the GCC command line.

When the file to be generated is libmylib. LA, for example:

$ Libtool -- mode = link GCC-O libmylib. La-rpath/usr/lib-L/usr/lib-la

The search of the dependent libraries is similar, but the corresponding shared libraries and static libraries are generated according to the corresponding rules at this time.

Note: libtool only involves the libtool file with the suffix la when linking. The actual library file name and library installation path and dependency are read from the file.

2 Why use-wl, -- rpath-link-wl, dir?
Using libtool to solve the compilation problem does not seem to be a problem: the Library name, path, and dependency have been well solved. However, don't worry about the conclusion. An obvious problem is that not all libraries are compiled using libtool.

For example, in the example above,

$ Libtool -- mode = link GCC-O myprog-rpath/usr/lib-L/usr/lib-la

If LIBA. So is not generated using the libtool, libtool cannot find the LIBA. La file at this time (this file does not exist ). In this case, libtool only transmits "-l/usr/lib-La" as a parameter to the GCC command line.

Consider the following. o file compilation and generation of myprog, which relies on library LIBA. so (generated using libtool), LIBA. so depends on libb again. so (libb. so generation does not use libtool), and for some reason, A's dependency on B is not written to LIBA. in LA, use the following command to compile:

$ Libtool -- mode = link GCC-O myprog-rpath/usr/lib-L/usr/lib-la

The GCC command line is similar to the following:

Gcc-O myprog/usr/lib/LIBA. So

Because LIBA. so depends on libb. so (this dependency can be read by readelf LIBA. so's ELF File), and the above command line does not show libb. so. Therefore, problems may occur.

It is "possible" because GCC cannot find a library (such as the above LIBA. so) other dependent libraries (such as libb. so), the linker will follow a certain policy to find the desired shared library under some paths:

1. All search paths specified by the '-rpath-link' option.

2. all search paths specified by '-rpath. the difference between '-rpath' and'-rpath_link 'is that the path specified by'-rpath' is included in the executable file and used during runtime, the '-rpath-link' option only works during connection.

3. in an elf system, if the '-rpath' and 'rpath-link' options are not used, the content of the environment variable 'LD _ run_path' will be searched. it only works for local connectors.

4. On SunOS, the '-rpath' option is not used. Only all Directories specified by'-l' are searched.

5. For a local connector, the content of the environment variable 'LD _ LIBRARY_PATH 'is searched.

6. for a local elf connector, The 'dt _ runpath' and 'dt _ rpath' operators in the shared library are searched by the shared library. if 'dt _ runpath' exists, 'dt _ rpath' is ignored.

7. default directory, such as '/lib' and'/usr/lib '.

8. For the local connector on the elf system, if the file '/etc/lD. So. conf' exists, some directories in this file will be searched.

As can be seen from the above, when using the local tool chain for local compilation, as long as the inventory is somewhere, GCC can always find the desired shared library through the above policy. However, in cross-compilation, only two of the above eight policies can be used:-rpath-link and-rpath. These two options have the highest priority among the above eight policies. If the two options are specified, if the shared library to be linked cannot be found, the linker takes precedence over the paths specified by these two options to search for the desired shared library. The above description shows that the path specified by-rpath will be written to the executable file;-rpath-link will not; we certainly do not want the path information used in cross-compilation to be written into the final executable file, so we choose to use option-rpath-link.

The GCC option "-wl, -- rpath-link-wl, Dir" will pass the-rpath-link option and path information to the linker. Return to the example above, if the command line does not contain libb. so, but GCC specifies "-wl, -- rpath-link-wl, Dir", then the linker cannot find libb. in so, first find the dependent library in the path specified by-rpath-link. Here we use the compilation command example to use the tool chain of the Unicore platform.

$ Unicore32-linux-gcc-O myprog/usr/lib/LIBA. So/

-Wl, -- rpath-link-wl,/home/unity_float/install/usr/lib

In this way, the compiler will first search for libb. So under "/home/unity_float/install/usr/lib ".

How does libtool pass the option "-wl, -- rpath-link-wl, Dir" to GCC? Libtool has a variable "hardcode_libdir_flag_spec" that would have passed the "-rpath" option, but we can modify it, add the path we need, and pass it to the unicore32-linux-gcc.

The original definition of "hardcode_libdir_flag_spec" is as follows:

Hardcode_libdir_flag_spec = "/$ {WL} -- rpath/$ {WL}/$ libdir"

The modified definition is as follows:

Hardcode_libdir_flag_spec = "/$ {WL}-rpath-link/$ {WL}/$ libdir/

-Wl, -- rpath-link-wl,/home/unity_float/install/usr/lib/

-Wl, -- rpath-link-wl,/home/unity_float/install/usr/x11r6/lib"

In this way, when libtool is in "-- mode = link" mode, it will pass the option "-wl, -- rpath-link-wl, Dir" to the GCC compiler.