分类: LINUX
2010-03-09 14:28:36
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 两个目录作为默认的库搜索路径,所以使用这两个目录中的库时无需进行配置搜索路径即可直接使用。对于处于默认库搜索路径之外的库,需要将库的位置添加到 库的搜索路径之中。配置库文档的搜索路径有下列两种方式,可任选其一使用: 添加方法也极其简单,将库文档的绝对路径直接写进去就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 至此,库的两种配置就完成了。 原文地址 http://hi.baidu.com/dexinmeng/blog/item/5512cf018b8941d5277fb571.html PKG_CONFIG_PATH: specify the path of *.pc file. The *.pc file is used for compile and link. LD_LIBRARY_PATH: specify the path of shared lib. used for runtime. |