ld.so.conf 文档和PKG_CONFIG_PATH变量

本文介绍了如何使用 pkg-config 工具来简化库文件的编译和链接过程,通过配置环境变量 PKG_CONFIG_PATH 和 LD_LIBRARY_PATH 来指定库文件的位置,确保在不同系统环境下的一致性和兼容性。

一、编译和连接
        一般来说,假如库的头文档不在 /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
至此,库的两种配置就完成了。


原文地址
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.
               
               
               

本文来自ChinaUnix博客,假如查看原文请点: http://blog.chinaunix.net/u2/60303/showart_492899.html
<think>好的,我现在要解决用户在Linux环境下配置动态链接库路径后,添加/etc/ld.so.conf.d/目录下的文件却不起作用的问题。首先,我需要回忆一下动态链接库的加载机制相关配置步骤。 根据用户提供的引用资料,特别是引用[2],系统默认只会搜索/lib/usr/lib,而通过源码安装的库可能放在/usr/local/lib或其他自定义路径,这时候就需要将这些路径添加到ld.so.conf.conf文件中。用户已经按照说明在/etc/ld.so.conf.d/目录下创建了.conf文件并写入路径,但问题仍然存在。那可能的原因是什么呢? 首先,我需要确认用户是否正确执行了ldconfig命令。根据引用[3],修改配置文件后必须运行sudo ldconfig来更新缓存,否则系统不会识别新的路径。这是常见的疏忽,用户可能忘记执行这一步,导致配置未生效。 其次,检查.conf文件的格式是否正确。每个路径应该独占一行,且没有拼写错误。例如,用户可能误将路径写成了/usr/local/lib/(末尾的斜杠可能不影响,但最好保持一致),或者路径本身不存在。需要确认路径是否真实存在,并且包含所需的.so文件。 另外,查看引用的内容中提到,除了ld.so.conf.d中的文件,还可以通过环境变量LD_LIBRARY_PATH或编译时指定rpath。如果用户同时使用了其他方法,可能会有冲突,需要检查是否有覆盖的情况。 还有可能权限问题,例如.conf文件的权限不正确,导致ldconfig无法读取。应该确保这些文件具有适当的读取权限,比如644。 再考虑是否修改了错误的配置文件,比如在/etc/ld.so.conf.d/中创建的.conf文件是否命名正确,没有后缀错误,例如应该是.conf而不是其他扩展名。或者是否放错了目录,比如误放在其他地方。 最后,可能需要检查系统日志,使用dmesg或查看/var/log/messages中的信息,看是否有加载库失败的具体错误信息,帮助进一步诊断问题。 总结可能的原因: 1. 未运行ldconfig更新缓存。 2. .conf文件格式或路径错误。 3. 路径不存在或权限问题。 4. 其他配置冲突,如环境变量覆盖。 5. 配置文件命名或位置错误。 接下来,需要将这些可能性转化为解决方案,并建议用户逐步排查。同时,根据引用[2][3]中的方法,确保用户正确执行每一步,特别是ldconfig命令。</think>### 解决方案:配置动态链接库路径后使其生效的步骤 1. **确认配置文件格式正确** - 在`/etc/ld.so.conf.d/`目录下新建的`.conf`文件(例如`my_libs.conf`),需确保文件中每行仅包含一个**绝对路径**,例如: ``` /usr/local/lib /opt/custom/lib ``` - 避免拼写错误或多余符号(如`~`代替家目录),路径需实际存在且包含`.so`文件。 2. **执行`ldconfig`更新缓存** - 修改配置文件后,必须运行以下命令使配置生效: ```bash sudo ldconfig ``` - 此命令会重新加载所有配置路径到动态链接器缓存中[^2][^3]。 3. **验证路径是否生效** - 使用以下命令检查动态链接器是否已包含新路径: ```bash ldconfig -v | grep <your_path> ``` 例如:`ldconfig -v | grep /usr/local/lib` - 若路径未显示,需检查配置文件命名(需以`.conf`结尾)权限(需可读)。 4. **排查常见问题** - **路径权限问题**:确保目标目录及其`.so`文件对其他用户可读(权限建议`755`)。 - **环境变量冲突**:若同时设置了`LD_LIBRARY_PATH`,可能覆盖配置文件中的路径。可通过临时取消该变量验证: ```bash unset LD_LIBRARY_PATH ``` - **路径实际存在性**:使用`ls <path>`确认目录存在且包含所需的库文件。 5. **替代方案(可选)** - **编译时指定路径**:在编译程序时通过`-Wl,-rpath=<path>`直接嵌入库搜索路径,例如: ```bash gcc -Wl,-rpath=/usr/local/lib -o program program.c ``` 此方法绕过系统级配置,仅影响当前程序。 --- ### 相关问题 1. **如何临时添加动态链接库路径而不修改系统配置?** - 通过环境变量`LD_LIBRARY_PATH`实现: ```bash export LD_LIBRARY_PATH=/your/path:$LD_LIBRARY_PATH ``` 2. **`ldconfig`命令的作用是什么?** - 用于更新系统的共享库缓存(`/etc/ld.so.cache`),使动态链接器能快速定位库文件[^2]。 3. **为什么某些库需要同时配置`PKG_CONFIG_PATH`?** - `PKG_CONFIG_PATH`用于帮助编译工具(如`gcc`)查找`.pc`元数据文件,而`ldconfig`仅影响运行时库加载[^2]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值