The difference between so, O, Lo, a, and La files under Linux __linux

o: Compiled target files
A: The static library, in fact, is a number of O files in a package
So: Dynamic link library (shared library)

Lo: The object file compiled with Libtool is actually adding some information to the O file
LA: A library file compiled using Libtool is actually a text file that records information about dynamic libraries and static libraries with the same name

1 Working principle of Libtool
Libtool is a general-purpose library support script that hides the complexity of using dynamic libraries in a unified, portable interface; Using Libtool's standard approach, you can create and invoke dynamic libraries on different platforms. You can think of Libtool as an abstraction of GCC that wraps gcc (or some other compiler), and users don't need to know the details, just tell Libtool which libraries to compile, and Libtool will handle the details of the library's dependencies. Libtool only deals with libtool files with the suffix named Lo and La.

One of the main roles of Libtool is to solve the problem of library dependencies in compiling large software, and to take the maintenance of heavy library dependencies and release the programmer's human resources. Libtool provides a unified interface that hides the differences between the names of different platforms, generates an abstract suffix named La High-level library libxx.la (actually a text file), and the dependencies of that library on other libraries are written in the La file. The dependency_libs in the file records all the libraries that the library relies on (some of which are added as a. La file), libdir the location where the library was installed, library_names the name of the shared library, and Old_library records the name of the static library.

When the compile process is in the link phase, if the following command is available:

$libtool--mode=link Gcc-o Myprog-rpath/usr/lib–l/usr/lib–la

Libtool will go down to the/usr/lib path to look for liba.la, and then read the actual shared library name (Library_names recorded the name, such as liba.so) and the path (Lib_dir, for example, Libdir= '/usr/ Lib '), returns parameters such as/usr/lib/liba.so to the GCC command line that is fired.

If liba.so relies on the library/usr/lib/libb.so, there will be dependency_libs= '-l/usr/lib-lb ' or dependency_libs= '/usr/lib/libb.la ' in liba.la Row, if it is the former, it will pass "-l/usr/lib–lb" as an argument directly to the GCC command line, and if it is the latter, Libtool will read the actual libb.so library name and path from/usr/lib/libb.la and then combine them into parameters "/usr/lib /libb.so is passed to the GCC command line.

When the files to be generated are such as libmylib.la, for example:

$libtool--mode=link Gcc-o Libmylib.la-rpath/usr/lib–l/usr/lib–la

The libraries relied on are basically similar searches, but at this point the corresponding shared libraries and static libraries are generated according to the corresponding rules.

Note: The Libtool link will only involve libtool files with a suffix named LA, and the actual library file name and library installation path and dependencies are read from the file.

2 Why use-WL,--rpath-link-wl,dir.
Using Libtool to solve a compilation problem looks fine: the name, path, and dependencies of the library are well resolved. But the conclusion is not so anxious, one obvious question is: Not all libraries are compiled with Libtool.

Like 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 tool, then Libtool cannot find the liba.la file at this time (the file does not exist). In this case, Libtool will only pass "–l/usr/lib–la" as an argument to the GCC command line.

Consider the following scenario: To compile the build Myprog from the MYPROG.O file, which relies on the library liba.so (generated using libtool), Liba.so relies on libb.so (libb.so does not use Libtool), and for some reason, A's dependency on B is not written to Lib A.la, then if you compile with the following command:

$libtool--mode=link Gcc-o Myprog-rpath/usr/lib–l/usr/lib–la

The fired GCC command line is similar to the following:

Gcc–o myprog/usr/lib/liba.so

Because Liba.so relies on libb.so (which can be seen with readelf read liba.so elf files), there is no libb.so on the command line above, so problems may occur.

"Possible" is because if, in the case of local compilation, GCC cannot find a library (such as the liba.so) on the command line that relies on other libraries (such as libb.so), the linker will follow a strategy to some path to find the shared library that is needed:

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 at run time, and the '-rpath-link ' option only works when connected.

3. In an elf system, if the '-rpath ' and ' rpath-link ' options are not used, the contents of the environment variable ' ld_run_path ' are searched. It also works only with local connectors.

4. On SunOS, the '-rpath ' option is not used and only searches for all directories specified by '-l '.

5. For a local connector, the contents of the environment variable ' ld_library_path ' are searched.

6. For a local Elf connector, the ' Dt_runpath ' and ' dt_rpath ' operators in the shared library are searched by their shared libraries. If ' Dt_runpath ' exists, the ' Dt_rpath ' will be ignored.

7. Default directory, regular, such as '/lib ' and '/usr/lib '.

8. For local connectors on the ELF system, if the file '/etc/ld.so.conf ' exists, some directories in this file will be searched.

As you can see from the above, when you use the local tool chain for local compilation, GCC always finds the shared library you need, as long as the inventory is in a certain location. But under the cross compilation, the above eight kinds of strategy, can use only have two:-rpath-link,-rpath. These two options have the highest precedence in the above eight strategies, and when you specify both options, if the shared library that the link requires is not found, the linker takes precedence over the path specified by the two options to search for the shared library that you want. As you can see from the above description, the path specified by-rpath will be written to the executable,-rpath-link will not; we certainly do not want the path information used in the cross compilation to be written into the final executable file, so we choose to use the option-rpath-link.

The GCC option "-WL,--rpath-link–wl,dir" will pass-rpath-link options and path information to the linker. Back to the example above, if libb.so is not present in the command line, but GCC specifies "-wl,--rpath-link–wl,dir", the linker cannot find libb.so, first to the later-rpath-link the specified path to find the library it relies on. Examples of the compilation commands we use here are the tool chains that use 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 first goes under "/home/unity_float/install/usr/lib" to search for libb.so

Libtool How to pass the option "-WL,--rpath-link–wl,dir" to GCC. There is a variable "Hardcode_libdir_flag_spec" in the libtool that is supposed to pass the "-rpath" option, but we can modify it, add the path we need, and pass it to UNICORE32-LINUX-GCC.

The original definition of "Hardcode_libdir_flag_spec" is as follows:

hardcode_libdir_flag_spec= "\${wl}--rpath \${wl}\ $libdir"

Our revised 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, the option "-wl,--rpath-link–wl,dir" is passed to the GCC compiler.