linux 编译: pkg-config

pkg-config命令详解

返回已安装库文件的元信息。

环境变量：PKG_CONFIG_PATH。pkg-config将在该变量下查找全部的.pc文件。此外，它还会查找/usr/lib/pkgconfig/下的.pc文件。

pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows. It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present. (A copy of glib 1.2.8 is shipped together with pkg-config and this is sufficient for pkg-config to compile and work properly.)

库文件编译完成后，会在{installed_home/lib/}下生成产生一个名为pkgconfig的目录，内含该连接库的.pc文件。这时须要将该文件复制到/usr/lib/pkgconfig/目录中或在环境变量中指定该文件的路径。这样作的目的是为了使依赖此连接库的其它程序可以借助pkg-config自动加载该库，避免编译期错误。 参数列表 –list 列出全部已安装的共享库 –cflags 列出指定共享库的预处理和编译flag。 –libs 列出指定共享库的连接flag。

1、编译和链接

通常来讲，若是库的头文件不在 /usr/include 目录中，那么在编译的时候须要用 -I 参数指定其路径。因为同一个库在不一样系统上可能位于不一样的目录下，用户安装库的时候也能够将库安装在不一样的目录下，因此即便使用同一个库，因为库的路径的不一样，形成了用 -I 参数指定的头文件的路径也可能不一样，其结果就是形成了编译命令界面的不统一。若是使用 -L 参数，也会形成链接界面的不统一。编译和链接界面不统一会为库的使用带来麻烦。

为了解决编译和链接界面不统一的问题，人们找到了一些解决办法。其基本思想就是：事先把库的位置信息等保存起来，须要的时候再经过特定的工具将其中有用的信息提取出来供编译和链接使用。这样，就能够作到编译和链接界面的一致性。其中，目前最为经常使用的库信息提取工具就是下面介绍的 pkg-config。

pkg-config 是经过库提供的一个 .pc 文件得到库的各类必要信息的，包括版本信息、编译和链接须要的参数等。这些信息能够经过 pkg-config 提供的参数单独提取出来直接供编译器和链接器使用。

The pkgconfig package contains tools for passing the include path and/or library paths to build tools during the make file execution.

pkg-config is a function that returns meta information for the specified library.

The default setting for PKG_CONFIG_PATH is /usr/lib/pkgconfig because of the prefix we use to install pkgconfig. You may add to PKG_CONFIG_PATH by exporting additional paths on your system where pkgconfig files are installed. Note that PKG_CONFIG_PATH is only needed when compiling packages, not during run-time.

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

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 的 --cflags 参数能够给出在编译时所须要的选项，而 --libs 参数能够给出链接时的选项。例如，假设一个 sample.c 的程序用到了 Glib 库，就能够这样编译：

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

而后这样链接：

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

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

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

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

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

1. 库自己在安装的时候必须提供一个相应的 .pc 文件。不这样作的库说明不支持 pkg-config 工具的使用。

2. pkg-config 必须知道要到哪里去寻找此 .pc 文件。

GTK+ 及其依赖库支持使用 pkg-config 工具，因此剩下的问题就是如何告诉 pkg-config 到哪里去寻找库对应的 .pc 文件，这也是经过设置搜索路径来解决的。对于支持 pkg-config 工具的 GTK+ 及其依赖库来讲，库的头文件的搜索路径的设置变成了对 .pc 文件搜索路径的设置。.pc 文件的搜索路径是经过环境变量 PKG_CONFIG_PATH 来设置的，pkg-config 将按照设置路径的前后顺序进行搜索，直到找到指定的 .pc 文件为止。

安装完 Glib 后，在 bash 中应该进行以下设置：

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

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

$ 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 文件）:

export

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

export

LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH

以后，就能够用下面的方法进行库的设置了（其中的 source 命令也能够用 . 代替）：

$ source set_gtk-2.10

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

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

2、运行时

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

1. 在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。

2. 在 /etc/ld.so.conf 文件中添加库的搜索路径。

将本身可能存放库文件的路径都加入到/etc/ld.so.conf中是明智的选择添加方法也极其简单，将库文件的绝对路径直接写进去就OK了，一行一个。例如： /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 权限，设置也简单：

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

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

$ echo $LD_LIBRARY_PATH

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