Understanding Pkg-config Tools (Linux compilation AIDS)

Ext.: http://www.jb51.net/LINUXjishu/86519.html

Have you developed software under Unix or Linux? Write a program, compile and run completely normal, in your local work well, you put into the source control system. Then, tell your colleague that you can take it off. At this time, you long out of breath, a few days of work not in vain, how fresh air ah, you began to be on the go.

"Hi, how do I compile the past?" "You are still immersed in that wonderful feeling, your arms are full of strength, and there seems to be no problem that can overwhelm you." At this moment, the fool has shouted at you.

"No, my side is good!" "On the surface you said very polite, in fact, you have been scolded, really stupid, do not know what the brain to use." Maybe, you think right, last time, he made a simple mistake, not when you go to solve it.

He shouted three times, you have to put down your work, just that wonderful feeling has disappeared without a trace, but if you control the mood very well, belly gas will be scattered on him. Before you go to his computer, type make and press ENTER gracefully. How could it be wrong? You're in full confidence. However, the results on the screen are a bit of a blush, damn it, how can libxxx.so not get it?

You look for libxxx.so in the/usr directory, and you can't escape your eyes. Strange, libxxx.so how in/usr/local/lib under, not should under/usr/lib? You can not blame others, other people want to install in the line, the next time may also be installed in the/lib directory.

The above scene is not fictitious, I have experienced several times, obviously in this machine good, in other people's machine even compile to pass. Two people may have the same operating system, the required libraries are installed, but because of personal preferences, installed in different directories only. In this case, each time the skill of the past, with the patch-type method, the heart of the old mind to work elsewhere.

Today we are going to introduce the pkg-config, to solve the above problems provide a beautiful solution. From then on, you don't worry about it anymore. Pkg-config provides the following features:

Check the version number of the library. If the desired version of the library does not meet the requirements, it prints an error message to avoid linking the wrong version of the library file.
Gets the location of the header file for the compilation preprocessing parameters, such as the macro definition.
Get link parameters, such as the location of libraries and other libraries that depend on them, filenames, and other connection parameters.
Automatically joins the settings of other libraries that depend on it.
It's all automatic, and it doesn't matter where the library files are installed!

Before use, we talk about the principle of pkg-config, Pkg-config is not a genie, can get the above information out of thin air. In fact, in order for Pkg-config to get this information, ask the library provider to provide a. pc file. For example, gtk+-2.0 's PC file contents are as follows:

Copy CodeThe code is as follows:
Prefix=/usr
Exec_prefix=/usr
Libdir=/usr/lib
Includedir=/usr/include
Target=x11</p> <p>gtk_binary_version=2.4.0
Gtk_host=i386-redhat-linux-gnu</p> <p>name:gtk+
Description:gimp Tool Kit (${target} target)
version:2.6.7
Requires:gdk-${target}-2.0 ATK
Libs:-l${libdir}-lgtk-${target}-2.0
Cflags:-i${includedir}/gtk-2.0

This file is usually placed in/usr/lib/pkgconfig/or/usr/local/lib/pkgconfig/, but can also be placed anywhere else, such as X11 related PC files are placed in the/usr/x11r6/lib/pkgconfig Under the. In order for Pkgconfig to find your PC file, you have to set the path of the PC file in the environment variable Pkg_config_path.

Using the Pkg-config –cflags parameter gives you the options you need at compile time, and the –libs parameter gives you the option to connect. For example, suppose a sample.c program uses the Glib library, it can be compiled like this:

Copy CodeThe code is as follows:
$ Gcc-c ' pkg-config–cflags glib-2.0 ' sample.c

Then connect like this:

Copy CodeThe code is as follows:
$ gcc sample.o-o sample ' pkg-config–libs glib-2.0 '

Or the above two steps can also be combined to take the next step:

Copy CodeThe code is as follows:
$ gcc sample.c-o sample ' pkg-config–cflags–libs glib-2.0 '

You can see that because the Pkg-config tool is used to get the library's options, you can use the same compilation and connection commands, regardless of the directory in which the library is installed, to unify the compilation and connection interfaces.
There are two basic prerequisites for extracting the compilation and connection parameters of a library using the Pkg-config tool:

The library itself must provide a corresponding. pc file at the time of installation (the library description does not support the use of the Pkg-config tool).
Pkg-config must know where to look for this. pc file.
GTK + and its dependent libraries support the use of the Pkg-config tool, so the remaining question is how to tell Pkg-config where to find the corresponding. pc file for the library, which is also resolved by setting the search path.

For GTK + and its dependent libraries that support the Pkg-config tool, the search path setting for the header file of the library becomes the setting for the. pc File search Path: The search path for the PC file is set by the environment variable Pkg_config_path, pkg-config The search is performed in the order of the set path until the specified. pc file is found.

After installing Glib, the following settings should be set in bash:

Copy CodeThe code is as follows:
$ export pkg_config_path=/opt/gtk/lib/pkgconfig: $PKG _config_path

You can perform the following command to check whether the/opt/gtk/lib/pkgconfig path is already set in the PKG_CONFIG_PATH environment variable:

Copy CodeThe code is as follows:
$ echo $PKG _config_path

After this setting, other programs or libraries that use the glib library are compiled with Pkg-config knowing that the first thing to do is to/opt/gtk/lib/pkgconfig this directory to find glib-2.0.pc (GTK + and other dependent libraries. pc files will also be copied to this , they will search for their corresponding. pc files first. After that, the compilation and connection parameters of the library can be extracted by Pkg-config for the program to be used in compiling and connecting.

It is also important to note that the settings for the environment variable are valid only for the current terminal window. If you arrive at a terminal window that does not have the above settings, Pkg-config will not find the newly installed glib-2.0.pc file, which may cause subsequent installations (such as the installation of ATK after glib) to fail.

In our installation scenario, the settings for GTK + and its dependent libraries are made using environment variables, so if you want to use the newly installed GTK + libraries after the system restarts, or a new terminal window is opened, you need to reset Pkg_config_path and ld_ as above. Library_path environment variables.

This method of using GTK + has a process of setting up the library before using it. It's a little cumbersome, but it's one of the safest ways to use the GTK + library, without any impact on the system's already existing programs that use the GTK + library, such as the GNOME desktop.

In order to make the library easier to set up, you can save the following two sentences to a file (such as the set_gtk-2.10 file):

Copy CodeThe code is as follows:
Export Pkg_config_path=/opt/gtk/lib/pkgconfig: $PKG _config_path
Export Ld_library_path=/opt/gtk/lib: $LD _library_path

You can then use the following method to set up the library (where the source command is also available.) instead):

Copy CodeThe code is as follows:
$ source set_gtk-2.10

These settings are only necessary if you are developing an application with the new GTK + library, or if you are running a program that uses the new GTK + library.

If you want to avoid the trouble with the above settings before using the GTK + library, you can set the above two environment variables in the system configuration file (such as/etc/profile) or your own user profile (such as ~/.bash_profile); The search path of the library can also be set in/etc/ ld.so.conf files, and so on. This setting takes effect when the system starts, which can cause problems with programs that use GTK + to use the new version of the GTK + runtime. Of course, if you find that using the new version of GTK + instead of the old version is not a problem, it is convenient to use this setup method.

Library files are used when connecting (static libraries and shared libraries) and running (limited to programs that use shared libraries), and their search paths are set in the system. The general Linux system/lib and/usr/lib two directories as the default library search path, so using the libraries in these two directories does not need to set the search path can be used directly. For libraries that are outside the default library search path, you need to add the location of the library to the search path of the library. There are two ways to set the search path for a library file, which can be used as one of the following:

Specifies the search path for the library in the environment variable Ld_library_path.
Add a search path to the library in the/etc/ld.so.conf file.
It is a good idea to add the path of your own possible repository files to/etc/ld.so.conf. (^_^)

Adding a method is also extremely simple, the absolute path of the library file is written directly into the OK, one line. For example:

Copy CodeThe code is as follows:
/usr/x11r6/lib
/usr/local/lib
/opt/lib

It is important to note that the second search path is set up in a way that is sufficient for the location of the library (including shared libraries and static libraries) when the program is connected, but is not sufficient for the execution of programs that use shared libraries. This is because in order to speed up the location of shared libraries during program execution, and to avoid the inefficient use of search paths to find shared libraries, it is straightforward to read the library list file/etc/ld.so.cache from which to search. /etc/ld.so.cache is a non-text data file that cannot be edited directly, it is based on the search path set in/etc/ld.so.conf by/sbin/ldconfig command to set the shared library files under these search paths together (the Ldconfig command is executed with root permission). Therefore, in order to ensure the location of the library when the program executes, after setting the library search path in/etc/ld.so.conf, you must also run the/sbin/ldconfig command to update the/etc/ld.so.cache file. Ldconfig, simply put, it is the role of the/etc/ld.so.conf listed in the path of the library file cache to/etc/ld.so.cache for use. So when you have installed some library files (such as just installing glib or modifying ld.so.conf to add a new library path), you need to run/sbin/ldconfig so that all library files are cached to Ld.so.cache, if not, even if the library file is in the/usr/ LIB, but also will not be used, the results of the compilation process in the wrong, the lack of XXX library, to see the discovery plainly on that put, make want to scold computer stupid pig A. (^_^)

When a program is connected, the search Paths for library files (static libraries and shared libraries) can be explicitly specified with the-l parameter in addition to the settings above. Because the path set with-L is prioritized, the path to the library to which you want to connect is typically specified in this way when you connect.

As explained earlier, there are two ways to set up a library search path: Set in environment variable Ld_library_path and in the/etc/ld.so.conf file. The second setting requires root permission to change the/etc/ld.so.conf file and execute the/sbin/ldconfig command. Also, when the system restarts, all GTK2-based programs will use the newly installed GTK + library at run time. Unfortunately, due to the changes in the GTK + version, this can sometimes be a compatibility issue for applications, causing some programs to run abnormally. To avoid these cases, the setting of the search path for the library during the installation of GTK + and its dependent libraries takes the first approach. This setting does not require root privileges and is simple to set up:

Copy CodeThe code is as follows:
$ export ld_library_path=/opt/gtk/lib: $LD _library_path

You can use the following command to view the contents of the Ld_libray_path settings:

Copy CodeThe code is as follows:
$ echo $LD _library_path

Finally, let me conclude that Pkg_config_path mainly indicates the path of the. pc file, so that the Pkg-config tool can dynamically generate compilation and connection options based on the contents of the. pc file, such as Cflags (compile) and Libs (for connection), If you are using a dynamic link library, when the program is connected and running, the general Linux system uses the/lib and/usr/lib two directories as the default library search path, and for libraries that are outside the default library search path, the system administrator can set the LD_LIBRARY_PATH environment variable or Add a search path to the library in the etc/ld.so.conf file. It is worth noting that when using the GCC connection option, if you do not use the Pkg-config tool, you need to display the dynamic link library name of the declaration connection. Students who use GCC can view the following considerations.

Linux system, in order to let the dynamic link library can be shared by other programs in the system, its name should conform to lib*.so.* this format. If a dynamic-link library does not conform to this format, the Linux dynamic link Library automatic loader (LD) will not be able to search for this link library and other programs cannot share it. Format, the first * is usually represented as a shortened library name, and the second * is usually expressed as the version number of the library. As in my system, the basic C dynamic Link library name is libc.so.6, thread pthread dynamic link library name is libpthread.so.0 and so on. If you do not specify a version number, such as libmy.so, this is the format that meets the requirements.

Several important options for GCC commands:

-shared This option specifies to generate a dynamic connection library (let the connector generate the export symbol table of type T, and sometimes the export symbol of the weakly connected W type, without which the external program cannot connect. Equivalent to an executable file).
-fpic: represents compiled to a location-independent code, without this option, the compiled code is location-dependent, so dynamic loading is a way of copying code to meet the needs of different processes, but not to achieve the purpose of real code segment sharing.
-L.: Indicates that the library to be connected is in the current directory.
-lmy: There is an implicit naming convention when the compiler looks for a dynamic connection library, that is, precede the given name with Lib, followed by. So to determine the name of the library (libmy.so).
Of course, if you have root permissions, you can modify the/etc/ld.so.conf file, and then call/sbin/ldconfig to achieve the same purpose, but if there is no root permission, then only the output Ld_library_path method.

Understanding Pkg-config Tools (Linux compilation AIDS)