简述configure、pkg-config、pkg_config_path三者的关系

　转自：简述configure、pkg-config、pkg_config_path三者的关系

　　1、什么是configure

　　源码安装过程当中大多会用到configure这个程序，通常的configure都是一个script，执行时能够传入必要参数告知配置项目。

　　configure程序它会根据传入的配置项目检查程序编译时所依赖的环境以及对程序编译安装进行配置，最终生成编译所需的Makefile文件供程序Make读入使用进而调用相关编译程式(一般调用编译程序都是gcc)来编译最终的二进制程序。而configure脚本在检查相应依赖环境时(例：所依赖软件的版本、相应库版本等)，一般会经过pkg-config的工具来检测相应依赖环境。

　　2、什么是pkg-config

　　一、pkg-config介绍

　　pkg-config用来检索系统中安装库文件的信息。典型的是用做库的编译和链接。如在Makefile中：

^?View Code BASH

 

1 2 3

program: program.c   cc program.c `pkg-config --cflags --libs gnomeui`

　　二、pkg-config功能

　　通常来讲，若是库的头文件不在/usr/include目录中，那么在编译的时候须要用-I参数指定其路径。因为同一个库在不一样系统上可能位于不一样的目录下，用户安装库的时候也能够将库安装在不一样的目录下，因此即便使用同一个库，因为库的路径的不一样，形成了用-I参数指定的头文件的路径和在链接时使用-L参数指定lib库的路径均可能不一样，其结果就是形成了编译命令界面的不统一。可能因为编译，链接的不一致，形成同一份程序从一台机器copy到另外一台机器时就可能会出现问题。

　　pkg-config 就是用来解决编译链接界面不统一问题的一个工具。

　　它的基本思想：pkg-config是经过库提供的一个.pc文件得到库的各类必要信息的，包括版本信息、编译和链接须要的参数等。须要的时候能够经过pkg-config提供的参数(–cflags, –libs)，将所需信息提取出来供编译和链接使用。这样，无论库文件安装在哪，经过库对应的.pc文件就能够准肯定位,可使用相同的编译和链接命令，使得编译和链接界面统一。

　　它提供的主要功能有:

　　<1> 检查库的版本号。若是所需库的版本不知足要求，打印出错误信息，避免链接错误版本的库文件。
　　<2> 得到编译预处理参数，如宏定义，头文件的路径。
　　<3> 得到编译参数，如库及其依赖的其余库的位置，文件名及其余一些链接参数。
　　<4> 自动加入所依赖的其余库的设置。

　　三、glib-2.0的.pc文件内容举例
　　
　　在默认状况下，每一个支持 pkg-config 的库对应的.pc文件在安装后都位于安装目录中的lib/pkgconfig目录下。例如，咱们在上面已经将Glib安装在/opt/gtk目录下了，那么这个Glib库对应的.pc文件是 /opt/gtk/lib/pkgconfig目录下一个叫glib-2.0.pc的文件：

^?View Code BASH

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14

prefix=/opt/gtk/ exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include   glib_genmarshal=glib-genmarshal gobject_query=gobject-query glib_mkenums=glib-mkenums   Name: GLib Description: C Utility Library Version: 2.12.13 Libs: -L${libdir} -lglib-2.0 Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include

　　pkg-config –list-all

　　列出全部可以使用的包，位置在/usr/lib/pkgconfig ,此目录下都是各类.pc文件。/usr/local/lib/pkgconfig下面的libname.pc文件，新软件通常都会安装.pc文件，没有能够本身建立，而且设置环境变量PKG_CONFIG_PATH寻找.pc文件路径。
　　使用 pkg-config 的 –cflags 参数能够给出在编译时所须要的选项，而 –libs 参数能够给出链接时的选项。例如，假设一个 sample.c 的程序用到了 Glib 库，就能够这样编译：

^?View Code BASH

 

1	$ gcc -c `pkg-config --cflags glib-2.0` sample.c

　　而后这样链接：

^?View Code BASH

 

1	$ gcc sample.o -o sample `pkg-config --libs glib-2.0`

　　或者上面两步也能够合并为如下一步：

^?View Code BASH

 

1	$ gcc sample.c -o sample `pkg-config --cflags --libs glib-2.0`

　　能够看到：因为使用了pkg-config工具来得到库的选项，因此不论库安装在什么目录下，均可以使用相同的编译和链接命令，带来了编译和链接界面的统一。

　　使用pkg-config工具提取库的编译和链接参数有两个基本的前提：

　　<1> 库自己在安装的时候必须提供一个相应的.pc文件。不这样作的库说明不支持pkg-config工具的使用。
　　<2> pkg-config必须知道要到哪里去寻找此.pc 文件。

　　四、 环境变量PKG_CONFIG_PATH

　　环境变量PKG_CONFIG_PATH是用来设置.pc文件的搜索路径的，pkg-config按照设置路径的前后顺序进行搜索，直到找到指定的.pc 文件为止。这样，库的头文件的搜索路径的设置实际上就变成了对.pc文件搜索路径的设置。

　　在安装完一个须要使用的库后，好比Glib，一是将相应的.pc文件，如glib-2.0.pc拷贝到/usr/lib/pkgconfig目录下，二是经过设置环境变量PKG_CONFIG_PATH添加glib-2.0.pc文件的搜索路径。

　　添加环境变量PKG_CONFIG_PATH，在bash中应该进行以下设置：

^?View Code BASH

 

1	$ export PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH

　　能够执行下面的命令检查是否 /opt/gtk/lib/pkgconfig 路径已经设置在PKG_CONFIG_PATH环境变量中：

^?View Code BASH

 

1	$ echo $PKG_CONFIG_PATH

　　这样设置以后，使用Glib库的其它程序或库在编译的时候pkg-config就知道首先要到/opt/gtk/lib/pkgconfig这个目录中去寻找glib-2.0.pc了(GTK+和其它的依赖库的.pc文件也将拷贝到这里，也会首先到这里搜索它们对应的.pc文件)。以后，经过pkg-config就能够把其中库的编译和链接参数提取出来供程序在编译和链接时使用。

　　另外还须要注意的是：环境变量的设置只对当前的终端窗口有效。若是到了没有进行上述设置的终端窗口中，pkg-config将找不到新安装的glib-2.0.pc文件、从而可能使后面进行的安装(如Glib以后的Atk的安装)没法进行。

　　在咱们采用的安装方案中，因为是使用环境变量对GTK+及其依赖库进行的设置，因此当系统从新启动、或者新开一个终端窗口以后，若是想使用新安装的GTK+库，须要如上面那样从新设置PKG_CONFIG_PATH和LD_LIBRARY_PATH环境变量。

　　这种使用GTK+的方法，在使用以前多了一个对库进行设置的过程。虽然显得稍微繁琐了一些，但倒是一种最安全的使用GTK+库的方式，不会对系统上已经存在的使用了GTK+库的程序(好比GNOME桌面)带来任何冲击。

　为了使库的设置变得简单一些，能够把下面的这两句设置保存到一个文件中(好比set_gtk-2.10 文件):

^?View Code BASH

 

1 2	export PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH

　　其中的环境变量LD_LIBRARY_PATH变量主要是添加新安装库的搜索路径。以后，就能够用下面的方法进行库的设置了(其中的source命令也能够用.代替)：

^?View Code BASH

 

1	$ source set_gtk-2.10

　　只有在用新版的GTK+库开发应用程序、或者运行使用了新版GTK+库的程序的时候，才有必要进行上述设置。

　　若是想避免使用GTK+库以前上述设置的麻烦，能够把上面两个环境变量的设置在系统的配置文件中(如 /etc/profile)或者本身的用户配置文件中(如 ~/.bash_profile) ；库的搜索路径也能够设置在 /etc/ld.so.conf 文件中，等等。这种设置在系统启动时会生效，从而会致使使用 GTK+ 的程序使用新版的 GTK+ 运行库，这有可能会带来一些问题。固然，若是你发现用新版的GTK+代替旧版没有什么问题的话，使用这种设置方式是比较方便的。加入到~/.bashrc中，例如：

^?View Code BASH

 

1	PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig

　　重启以后：

^?View Code BASH

 

1 2	[root@localhost ~]# echo $PKG_CONFIG_PATH /opt/gtk/lib/pkgconfig

　　3、运行时库的链接

　　库文件在链接(静态库和共享库)和运行(仅限于使用共享库的程序)时被使用，其搜索路径是在系统中进行设置的。通常Linux系统把/lib和/usr/lib两个目录做为默认的库搜索路径，因此使用这两个目录中的库是不须要进行设置搜索路径便可直接使用。对于处于默认库搜索路径以外的库，须要将库的位置添加到 库的搜索路径之中。设置库文件的搜索路径有下列两种方式，可任选其一使用：

　　<1> 在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。
　　<2> 在/etc/ld.so.conf 文件中添加库的搜索路径。

　　将本身可能存放库文件的路径都加入到/etc/ld.so.conf中是明智的选择 ^_^

　　添加方法也极其简单，将库文件的绝对路径直接写进去就OK了，一行一个。例如：

^?View Code BASH

 

1 2 3

/usr/X11R6/lib /usr/local/lib /opt/lib

　　须要注意的是：第二种搜索路径的设置方式对于程序链接时的库(包括共享库和静态库)的定位已经足够了，可是对于使用了共享库的程序的执行仍是不够的。这是由于为了加快程序执行时对共享库的定位速度，避免使用搜索路径查找共享库的低效率，因此是直接读取库列表文件/etc/ld.so.cache从中进行搜索的。/etc/ld.so.cache是一个非文本的数据文件，不能直接编辑，它是根据/etc/ld.so.conf中设置的搜索路径由/sbin/ldconfig命令将这些搜索路径下的共享库文件集中在一块儿而生成的(ldconfig命令要以root权限执行)。所以，为了保证程序执行时对库的定位，在/etc/ld.so.conf中进行了库搜索路径的设置以后，还必需要运行/sbin/ldconfig命令更新/etc/ld.so.cache文件以后才能够。ldconfig简单的说，它的做用就是将/etc/ld.so.conf列出的路径下的库文件缓存到/etc/ld.so.cache以供使用。所以当安装完一些库文件(例如刚安装好glib)，或者修改ld.so.conf增长新的库路径后，须要运行一下 /sbin/ldconfig使全部的库文件都被缓存到ld.so.cache中，若是没作，即便库文件明明就在/usr/lib下的，也是不会被使用的，结果编译过程当中抱错，缺乏xxx库，去查看发现明明就在那放着，搞的想大骂computer蠢猪一个。 ^_^

　　在程序链接时，对于库文件(静态库和共享库)的搜索路径，除了上面的设置方式以外，还能够经过-L参数显式指定。由于用-L设置的路径将被优先搜索，因此在链接的时候一般都会以这种方式直接指定要链接的库的路径。

　　前面已经说明过了，库搜索路径的设置有两种方式：在环境变量LD_LIBRARY_PATH中设置以及在/etc/ld.so.conf文件中设置。其中，第二种设置方式须要root权限，以改变/etc/ld.so.conf文件并执行/sbin/ldconfig命令。并且，当系统从新启动后，全部的基于GTK2的程序在运行时都将使用新安装的GTK+库。不幸的是，因为GTK+版本的改变，这有时会给应用程序带来兼容性的问题，形成某些程序运行不正常。为了不出现上面的这些状况，在GTK+及其依赖库的安装过程当中对于库的搜索路径的设置将采用第一种方式进行。这种设置方式不须要root权限，设置也简单：

^?View Code BASH

 

1	$ export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH

　　能够用下面的命令查看 LD_LIBRAY_PATH 的设置内容：

^?View Code BASH

 

1	$ echo $LD_LIBRARY_PATH

　　至此，库的两种设置就完成了。

　　4、参考文章
　　
　　ld.so.conf 文件与PKG_CONFIG_PATH变量
　　pkg-config使用