linux源码安装之/ld.so.conf ; ldconfig ;configure;pkg-config PKG_CONFIG_PATH详解
2017-08-01 18:04
866 查看
首先说下/etc/ld.so.conf:
这个文件记录了编译时使用的动态链接库的路径。
默认情况下，编译器只会使用/lib和/usr/lib这两个目录下的库文件
如果你安装了某些库，比如在安装gtk+-2.4.13时它会需要glib-2.0 >=
2.4.0,辛苦的安装好glib后
没有指定 --prefix=/usr
这样glib库就装到了/usr/local下，而又没有在/etc/ld.so.conf中添加/usr/local/lib这个搜索路径，所以编译gtk+-2.4.13就会出错了
对于这种情况有两种方法解决：
一：在编译glib-2.4.x时，指定安装到/usr下，这样库文件就会放在/usr/lib中，gtk就不会找不到需要的库文件了
对于安装库文件来说，这是个好办法，这样也不用设置PKG_CONFIG_PATH了
二：将/usr/local/lib加入到/etc/ld.so.conf中，这样安装gtk时就会去搜索/usr/local/lib,同样可以找到需要的库
将/usr/local/lib加入到/etc/ld.so.conf也是必须的，这样以后安装东东到local下，就不会出现这样的问题了。
将自己可能存放库文件的路径都加入到/etc/ld.so.conf中是明智的选择
添加方法也极其简单，将库文件的绝对路径直接写进去就OK了，一行一个。例如：
/usr/X11R6/lib
/usr/local/lib
/opt/lib
再来看看ldconfig ：
它是一个程序，通常它位于/sbin下，是root用户使用的。具体作用及用法可以man
ldconfig查到
简单的说，它的作用就是将/etc/ld.so.conf列出的路径下的库文件
缓存到/etc/ld.so.cache 以供使用
因此当安装完一些库文件，(例如刚安装好glib)，或者修改ld.so.conf增加新的库路径后，需要运行一下/sbin/ldconfig
使所有的库文件都被缓存到ld.so.cache中，如果没做，即使库文件明明就在/usr/lib下的，也是不会被使用的，结果编译过程中报错，缺少xxx库
我曾经编译KDE时就犯过这个错误，(它需要每编译好一个东东，都要运行一遍)，所以切记改动库文件后一定要运行一下ldconfig，在任何目录下运行都可以。
再来说说 PKG_CONFIG_PATH这个变量吧:
经常在论坛上看到有人问"为什么我已经安装了glib-2.4.x，但是编译gtk+-2.4.x
还是提示glib版本太低阿？
为什么我安装了glib-2.4.x，还是提示找不到阿？。。。。。。"都是这个变量搞的鬼。
先说说它是哪冒出来的，当安装了pkgconfig-x.x.x这个包后，就多出了pkg-config，它就是需要PKG_CONFIG_PATH的东东
pkgconfig-x.x.x又是做什么的？ 来看一段说明：
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就是向configure程序提供系统信息的程序，比如软件的版本啦，库的版本啦，库的路径啦，等等
这些信息只是在编译其间使用。你可以 ls /usr/lib/pkgconfig
下，会看到许多的*.pc,用文本编辑器打开
会发现类似下面的信息：
prefix=/usr
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.4.7
Libs: -L${libdir} -lglib-2.0
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include
明白了吧，configure就是靠这些信息判断你的软件版本是否符合要求。并且得到这些东东所在的位置，要不去哪里找呀。
不用我说你也知道为什么会出现上面那些问题了吧。
解决的办法很简单，设定正确的PKG_CONFIG_PATH，假如将glib-2.x.x装到了/usr/local/下，那么glib-2.0.pc就会在
/usr/local/lib/pkgconfig下，将这个路径添加到PKG_CONFIG_PATH下就可以啦。并且确保configure找到的是正确的
glib-2.0.pc,就是将其他的lib/pkgconfig目录glib-2.0.pc干掉就是啦。(如果有的话
^-^)
设定好后可以加入到~/.bashrc中，例如：
PKG_CONFIG_PATH=/opt/kde-3.3.0/lib/pkgconfig:/usr/lib/pkgconfig:/usr/local/pkgconfig:
/usr/X11R6/lib/pkgconfig
[root@NEWLFS ~]#echo $PKG_CONFIG_PATH
/opt/kde-3.3.0/lib/pkgconfig:/usr/lib/pkgconfig:/usr/local/pkgconfig:/usr/X11R6/lib/pkgconfig
从上面可以看出，安装库文件时，指定安装到/usr，是很有好处的，无论是/etc/ld.so.conf还是PKG_CONFIG_PATH
默认都会去搜索/usr/lib的，可以省下许多麻烦，不过从源码包管理上来说，都装在/usr下
管理是个问题，不如装在/usr/local下方便管理
其实只要设置好ld.so.conf，PKG_CONFIG_PATH路径后，就OK啦
其实真正的第一步是./configure.似曾相识哦。没错，那么我也时常见过pkg-config及pkg_config_path.这几这到底啥关系呢，这就是今天的主题。
1.什么是configure
configure会根据传入的配置项目检查程序编译时所依赖的环境以及对程序编译安装进行配置，最终生成编译所需的Makefile文件供程序Make读入使用进而调用相关编译程式(通常调用编译程序都是gcc)来编译最终的二进制程序。而configure脚本在检查相应依赖环境时(例：所依赖软件的版本、相应库版本等)，通常会通过pkg-config的工具来检测相应依赖环境。
2.什么是pkg-config
pkg-config用来检索系统中安装库文件的信息，典型的是用作库的编译和连接。一般来说，如果库的头文件不在/usr/include目录中，那么在编译的时候需要用-I参数指定其路径。由于同一个库在不同系统上可能位于不同的目录下，用户安装库的时候也可以将库安装在不同的目录下，所以即使使用同一个库，由于库的路径的不同，造成了用-I参数指定的头文件的路径和在连接时使用-L参数指定lib库的路径都可能不同，其结果就是造成了编译命令界面的不统一。可能由于编译，连接的不一致，造成同一份程序从一台机器copy到另一台机器时就可能会出现问题。
pkg-config 就是用来解决编译连接界面不统一问题的一个工具。基本思想：pkg-config是通过库提供的一个.pc文件获得库的各种必要信息的，包括版本信息、编译和连接需要的参数等。需要的时候可以通过pkg-config提供的参数(–cflags, –libs)，将所需信息提取出来供编译和连接使用。这样，不管库文件安装在哪，通过库对应的.pc文件就可以准确定位,可以使用相同的编译和连接命令，使得编译和连接界面统一。它提供的主要功能有:
<1> 检查库的版本号。如果所需库的版本不满足要求，打印出错误信息，避免连接错误版本的库文件。
<2> 获得编译预处理参数，如宏定义，头文件的路径。
<3> 获得编译参数，如库及其依赖的其他库的位置，文件名及其他一些连接参数。
<4> 自动加入所依赖的其他库的设置。
在默认情况下，每个支持 pkg-config 的库对应的.pc文件在安装后都位于安装目录中的lib/pkgconfig目录下.新软件一般都会安装.pc文件，没有可以自己创建，并且设置环境变量PKG_CONFIG_PATH寻找.pc文件路径,否则怎么找得到呢。使用pkg-config工具提取库的编译和连接参数有两个基本的前提：
<1> 库本身在安装的时候必须提供一个相应的.pc文件。不这样做的库说明不支持pkg-config工具的使用。
<2> pkg-config必须知道要到哪里去寻找此.pc 文件。
3.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文件的搜索路径。
这样设置之后，使用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桌面)带来任何冲击。
一、编译和连接
一般来说，如果库的头文件不在 /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 工具提取库的编译和连接参数有两个基本的前提：
库本身在安装的时候必须提供一个相应的 .pc 文件。不这样做的库说明不支持 pkg-config 工具的使用。
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
二、运行时
库文件在连接（静态库和共享库）和运行（仅限于使用共享库的程序）时被使用，其搜索路径是在系统中进行设置的。一般 Linux
系统把 /lib 和 /usr/lib
两个目录作为默认的库搜索路径，所以使用这两个目录中的库时不需要进行设置搜索路径即可直接使用。对于处于默认库搜索路径之外的库，需要将库的位置添加到
库的搜索路径之中。设置库文件的搜索路径有下列两种方式，可任选其一使用：
在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。
在 /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
至此，库的两种设置就完成了。
这个文件记录了编译时使用的动态链接库的路径。
默认情况下，编译器只会使用/lib和/usr/lib这两个目录下的库文件
如果你安装了某些库，比如在安装gtk+-2.4.13时它会需要glib-2.0 >=
2.4.0,辛苦的安装好glib后
没有指定 --prefix=/usr
这样glib库就装到了/usr/local下，而又没有在/etc/ld.so.conf中添加/usr/local/lib这个搜索路径，所以编译gtk+-2.4.13就会出错了
对于这种情况有两种方法解决：
一：在编译glib-2.4.x时，指定安装到/usr下，这样库文件就会放在/usr/lib中，gtk就不会找不到需要的库文件了
对于安装库文件来说，这是个好办法，这样也不用设置PKG_CONFIG_PATH了
二：将/usr/local/lib加入到/etc/ld.so.conf中，这样安装gtk时就会去搜索/usr/local/lib,同样可以找到需要的库
将/usr/local/lib加入到/etc/ld.so.conf也是必须的，这样以后安装东东到local下，就不会出现这样的问题了。
将自己可能存放库文件的路径都加入到/etc/ld.so.conf中是明智的选择
添加方法也极其简单，将库文件的绝对路径直接写进去就OK了，一行一个。例如：
/usr/X11R6/lib
/usr/local/lib
/opt/lib
再来看看ldconfig ：
它是一个程序，通常它位于/sbin下，是root用户使用的。具体作用及用法可以man
ldconfig查到
简单的说，它的作用就是将/etc/ld.so.conf列出的路径下的库文件
缓存到/etc/ld.so.cache 以供使用
因此当安装完一些库文件，(例如刚安装好glib)，或者修改ld.so.conf增加新的库路径后，需要运行一下/sbin/ldconfig
使所有的库文件都被缓存到ld.so.cache中，如果没做，即使库文件明明就在/usr/lib下的，也是不会被使用的，结果编译过程中报错，缺少xxx库
我曾经编译KDE时就犯过这个错误，(它需要每编译好一个东东，都要运行一遍)，所以切记改动库文件后一定要运行一下ldconfig，在任何目录下运行都可以。
再来说说 PKG_CONFIG_PATH这个变量吧:
经常在论坛上看到有人问"为什么我已经安装了glib-2.4.x，但是编译gtk+-2.4.x
还是提示glib版本太低阿？
为什么我安装了glib-2.4.x，还是提示找不到阿？。。。。。。"都是这个变量搞的鬼。
先说说它是哪冒出来的，当安装了pkgconfig-x.x.x这个包后，就多出了pkg-config，它就是需要PKG_CONFIG_PATH的东东
pkgconfig-x.x.x又是做什么的？ 来看一段说明：
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就是向configure程序提供系统信息的程序，比如软件的版本啦，库的版本啦，库的路径啦，等等
这些信息只是在编译其间使用。你可以 ls /usr/lib/pkgconfig
下，会看到许多的*.pc,用文本编辑器打开
会发现类似下面的信息：
prefix=/usr
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.4.7
Libs: -L${libdir} -lglib-2.0
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include
明白了吧，configure就是靠这些信息判断你的软件版本是否符合要求。并且得到这些东东所在的位置，要不去哪里找呀。
不用我说你也知道为什么会出现上面那些问题了吧。
解决的办法很简单，设定正确的PKG_CONFIG_PATH，假如将glib-2.x.x装到了/usr/local/下，那么glib-2.0.pc就会在
/usr/local/lib/pkgconfig下，将这个路径添加到PKG_CONFIG_PATH下就可以啦。并且确保configure找到的是正确的
glib-2.0.pc,就是将其他的lib/pkgconfig目录glib-2.0.pc干掉就是啦。(如果有的话
^-^)
设定好后可以加入到~/.bashrc中，例如：
PKG_CONFIG_PATH=/opt/kde-3.3.0/lib/pkgconfig:/usr/lib/pkgconfig:/usr/local/pkgconfig:
/usr/X11R6/lib/pkgconfig
[root@NEWLFS ~]#echo $PKG_CONFIG_PATH
/opt/kde-3.3.0/lib/pkgconfig:/usr/lib/pkgconfig:/usr/local/pkgconfig:/usr/X11R6/lib/pkgconfig
从上面可以看出，安装库文件时，指定安装到/usr，是很有好处的，无论是/etc/ld.so.conf还是PKG_CONFIG_PATH
默认都会去搜索/usr/lib的，可以省下许多麻烦，不过从源码包管理上来说，都装在/usr下
管理是个问题，不如装在/usr/local下方便管理
其实只要设置好ld.so.conf，PKG_CONFIG_PATH路径后，就OK啦
其实真正的第一步是./configure.似曾相识哦。没错，那么我也时常见过pkg-config及pkg_config_path.这几这到底啥关系呢，这就是今天的主题。
1.什么是configure
configure会根据传入的配置项目检查程序编译时所依赖的环境以及对程序编译安装进行配置，最终生成编译所需的Makefile文件供程序Make读入使用进而调用相关编译程式(通常调用编译程序都是gcc)来编译最终的二进制程序。而configure脚本在检查相应依赖环境时(例：所依赖软件的版本、相应库版本等)，通常会通过pkg-config的工具来检测相应依赖环境。
2.什么是pkg-config
pkg-config用来检索系统中安装库文件的信息，典型的是用作库的编译和连接。一般来说，如果库的头文件不在/usr/include目录中，那么在编译的时候需要用-I参数指定其路径。由于同一个库在不同系统上可能位于不同的目录下，用户安装库的时候也可以将库安装在不同的目录下，所以即使使用同一个库，由于库的路径的不同，造成了用-I参数指定的头文件的路径和在连接时使用-L参数指定lib库的路径都可能不同，其结果就是造成了编译命令界面的不统一。可能由于编译，连接的不一致，造成同一份程序从一台机器copy到另一台机器时就可能会出现问题。
pkg-config 就是用来解决编译连接界面不统一问题的一个工具。基本思想：pkg-config是通过库提供的一个.pc文件获得库的各种必要信息的，包括版本信息、编译和连接需要的参数等。需要的时候可以通过pkg-config提供的参数(–cflags, –libs)，将所需信息提取出来供编译和连接使用。这样，不管库文件安装在哪，通过库对应的.pc文件就可以准确定位,可以使用相同的编译和连接命令，使得编译和连接界面统一。它提供的主要功能有:
<1> 检查库的版本号。如果所需库的版本不满足要求，打印出错误信息，避免连接错误版本的库文件。
<2> 获得编译预处理参数，如宏定义，头文件的路径。
<3> 获得编译参数，如库及其依赖的其他库的位置，文件名及其他一些连接参数。
<4> 自动加入所依赖的其他库的设置。
在默认情况下，每个支持 pkg-config 的库对应的.pc文件在安装后都位于安装目录中的lib/pkgconfig目录下.新软件一般都会安装.pc文件，没有可以自己创建，并且设置环境变量PKG_CONFIG_PATH寻找.pc文件路径,否则怎么找得到呢。使用pkg-config工具提取库的编译和连接参数有两个基本的前提：
<1> 库本身在安装的时候必须提供一个相应的.pc文件。不这样做的库说明不支持pkg-config工具的使用。
<2> pkg-config必须知道要到哪里去寻找此.pc 文件。
3.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文件的搜索路径。
这样设置之后，使用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桌面)带来任何冲击。
一、编译和连接
一般来说，如果库的头文件不在 /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 工具提取库的编译和连接参数有两个基本的前提：
库本身在安装的时候必须提供一个相应的 .pc 文件。不这样做的库说明不支持 pkg-config 工具的使用。
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
二、运行时
库文件在连接（静态库和共享库）和运行（仅限于使用共享库的程序）时被使用，其搜索路径是在系统中进行设置的。一般 Linux
系统把 /lib 和 /usr/lib
两个目录作为默认的库搜索路径，所以使用这两个目录中的库时不需要进行设置搜索路径即可直接使用。对于处于默认库搜索路径之外的库，需要将库的位置添加到
库的搜索路径之中。设置库文件的搜索路径有下列两种方式，可任选其一使用：
在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。
在 /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
至此，库的两种设置就完成了。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- linux源码安装之/ld.so.conf ; ldconfig ;configure;pkg-config PKG_CONFIG_PATH详解
- (转)/ld.so.conf ; ldconfig ; PKG_CONFIG_PATH详解
- ［源码包编译］关于/etc/ld.so.conf、ldconfig、pkg-config、PKG_CONFIG_PATH的一篇文章
- 源码安装软件 pkgconfig ld.so.conf ldconfig
- ld.so.conf 文件与PKG_CONFIG_PATH变量
- PKG_CONFIG_PATH变量 与 ld.so.conf 文件
- ld.so.conf 文件与PKG_CONFIG_PATH变量-ZT
- (转)/etc/ld.so.conf和ldconfig， PKG_CONFIG_PATH
- PKG_CONFIG_PATH变量 与 ld.so.conf 文件
- PKG_CONFIG_PATH变量 与 ld.so.conf 文件
- 关于pkg-config与LD_LIBRARY_PATH与/etc/ld.so.conf文件的区别与作用
- ld.so.conf 文件与PKG_CONFIG_PATH变量（转）
- /etc/ld.so.conf和ldconfig， PKG_CONFIG_PATH
- ld.so.conf 文件与PKG_CONFIG_PATH变量
- Linux源代码编译软件及PKG_CONFIG_PATH、LD_LIBRARY_PATH、/etc/ld.so.conf、ldconfig
- ld.so.conf 文件与PKG_CONFIG_PATH变量
- Linux源代码编译软件及PKG_CONFIG_PATH、LD_LIBRARY_PATH、/etc/ld.so.conf、ldconfig
- ld.so.conf 文件与PKG_CONFIG_PATH变量
- /etc/ld.so.conf & ldconfig & PKG_CONFIG_PATH[转]
- linux下链接动态库路径相关的/etc/ld.so.conf，ldconfig， PKG_CONFIG_PATH【整理】