Linux上的动态链接库依赖问题 (linux下依赖dll)

在Linux操作系统上,动态链接库是非常重要的一部分。它们为应用程序提供了一种共享代码的方式,减少了内存使用和增加了系统的安全性。然而,动态链接库也会带来一些依赖问题,在本文中,我们将深入探讨这些问题。

一、动态链接库的基础知识

1.1 静态链接库和动态链接库

在编译应用程序时,有两种方式可以将代码与所依赖的库链接起来:静态链接和动态链接。静态链接库将所有依赖的库的代码复制到应用程序中,生成一个独立的可执行文件。而动态链接库则将依赖的库的代码放在一个单独的文件中,并在运行时加载到内存中。

1.2 动态链接库的优势

动态链接库相对于静态链接库有以下几个优势:

– 内存使用更加高效。静态链接库会导致应用程序内存使用更多,而动态链接库只需要将所需要的代码加载到内存中即可。

– 代码更新更加方便。如果一个应用程序依赖的库需要更新,对于静态链接库,需要重新编译整个应用程序;而对于动态链接库,只需要将新的库替换原来的库即可。

– 提高系统的安全性。静态链接库可能会包含某些安全漏洞,而动态链接库只需要更新单独的库即可修复漏洞。

二、Linux动态链接库依赖问题

动态链接库带来了很多优点,但也带来了一些挑战。其中最明显的问题就是动态链接库依赖问题。假设应用程序A使用了动态链接库B,并且B也依赖了动态链接库C,那么在运行时,A需要正确地找到和加载B和C。如果找不到依赖的库,应用程序将无法运行。下面将介绍几个可能出现的问题。

2.1 依赖库路径问题

当应用程序需要一个动态链接库时,它会去系统预定的搜索路径中寻找依赖的库,如/lib, /usr/lib 或/usr/local/lib。如果依赖的库不在这些路径中,则应用程序无法找到它。

解决这个问题的方法有以下几种:

– 将库复制到搜索路径中。如果库不在搜索路径中,则可以使用cp命令将其复制到相应的路径。

– 在运行程序时指定依赖库的路径。可以使用LD_LIBRARY_PATH环境变量或者使用ldd命令查看依赖的库路径,并用export命令设置该环境变量。

– 在运行程序时指定依赖库的位置。可以在编译应用程序时使用-l选项指定库的位置。

2.2 依赖库版本问题

动态链接库可以有不同的版本,不同的版本可能并不兼容。例如,当应用程序需要版本为1.0的动态链接库A时,但系统上只存在1.1版本的库A,那么在运行时就会出现版本不兼容的问题。

解决这个问题可以通过以下几种方式:

– 在编译应用程序时,使用-l选项指定需要的库的版本。

– 在运行程序时,使用LD_LIBRARY_VERSION环境变量来指定依赖库的版本。

– 在运行程序时,指定依赖库的路径及版本号。

2.3 依赖库的缺失和错误

如果应用程序依赖的库缺失或出现错误,应用程序将无法正常运行。解决这个问题需要确保依赖的库存在,并且没有错误。

对于缺失的库,可以使用以下几种方法:

– 安装缺失的库。可以使用包管理工具安装缺失的库。

– 在运行程序时指定依赖库的路径,如使用LD_LIBRARY_PATH环境变量。

对于库出现错误的情况,比如库损坏、病毒感染等,需要对库进行修复或者重新安装。

三、

动态链接库是Linux系统中非常关键的一部分,它可以提高系统内存使用效率,简化代码更新和维护,提高系统的安全性。但动态链接库也会带来一些挑战,最明显的问题是依赖问题。为了解决这个问题,需要正确设置搜索路径、版本号和确保依赖的库存在和没有错误。理解和解决依赖问题对于Linux软件开发和系统维护都是非常重要的。

相关问题拓展阅读:

SUSE Linux 11下glibc依赖问题

0.以下在系统CentOS 6.3 x86_64上操作

1.试图运行程序,提示”libc.so.6: version `GLIBC_2.14′ not found”,原因是系统的glibc版本太低,软件编译时使用了较高版本的glibc引起的:

 view plain copy

$ pwd  

/var/VMdisks/cross/mingw32/bin  

$ ls  

lrelease     QtCore4.dllQtNetwork4.dll      QtSql4.dll     QtXml4.dll  

mocQtDeclarative4.dll  QtOpenGL4.dllQtSvg4.dll     rcc  

phonon4.dll  QtGui4.dllQtScript4.dllQtTest4.dll    uic  

qmakeQtMultimedia4.dll   QtScriptTools4.dll  QtWebKit4.dll  

$ ./qmake   

./qmake: /lib64/libc.so.6: version `GLIBC_2.14′ not found (required by ./qmake)  

2.查看系统glibc支持的版本:

 view plain copy

$ strings /lib64/libc.so.6 |grep GLIBC_  

GLIBC_2.2.5  

GLIBC_2.2.6  

GLIBC_2.3  

GLIBC_2.3.2  

GLIBC_2.3.3  

GLIBC_2.3.4  

GLIBC_2.4  

GLIBC_2.5  

GLIBC_2.6  

GLIBC_2.7  

GLIBC_2.8  

GLIBC_2.9  

GLIBC_2.10  

GLIBC_2.11  

GLIBC_2.12  

GLIBC_PRIVATE  

 view plain copy

$ rpm -qa |grep glibc  

glibc-static-2.12-1.80.el6_3.6.x86_64  

glibc-headers-2.12-1.80.el6_3.6.x86_64  

glibc-common-2.12-1.80.el6_3.6.x86_64  

glibc-devel-2.12-1.80.el6_3.6.x86_64  

glibc-static-2.12-1.80.el6_3.6.i686  

glibc-devel-2.12-1.80.el6_3.6.i686  

glibc-2.12-1.80.el6_3.6.i686  

glibc-2.12-1.80.el6_3.6.x86_64  

3.可以看到更高只支持2.12版本,所以考虑编译解决这个问题:

a. 到下载最新版本,我这里下载了glibc-2.14.tar.xz 猛陆这个版本,解压到任意目录准备编译

b.这里解压到/var/VMdisks/glibc-2.14/

 view plain copy

$ cd /var/VMdisks/glibc-2.14/  

$ pwd  

/var/VMdisks/glibc-2.14  

$ ls  

abilistconfig.h.inintlREADME.libm  

abi-tagsconfig.logio 桥知则resolv  

aclocal.mconfig.make.inlibc-abis      resource  

aout configurelibidnrt  

argp configure.inlibioRules  

assert敏棚 conform LICENSESscripts  

autom4te.cache     CONFORMANCElocalesetjmp  

bits COPYING localedata     shadow  

BUGS COPYING.LIBloginshlib-versions  

buildcppflags-iterator.mk  machsignal  

CANCEL-FCT-WAIVE   crypt   Makeconfig     socket  

CANCEL-FILE-WAIVE  csu     Makefilesoft-fp  

catgetsctype   Makefile.in    stdio-common  

ChangeLogdebug   Makerules      stdlib  

ChangeLog.dirent  mallocstreams  

ChangeLog.dlfcn   manualstring  

ChangeLog.elf     mathsunrpc  

ChangeLog.extra-lib.mkmiscsysdeps  

ChangeLog.extra-modules.mk      NAMESPACE      sysvipc  

ChangeLog.FAQ     NEWStermios  

ChangeLog.FAQ.in  nistest-skeleton.c  

ChangeLog.gmon    NOTEStime  

ChangeLog.gnulib  nptltimezone  

ChangeLog.grp     nptl_dbtls.make.c  

ChangeLog.gshadow nscdversion.h  

ChangeLog.hesiod  nssVersions.def  

ChangeLog.hurd    o-iterator.mk  wcbs  

ChangeLog.iconv   powctype  

ChangeLog.iconvdataposixWUR-REPORT  

ChangeLog.include PROJECTS  

ChangeLog.inet    pwd  

conf INSTALL README  

c.在glibc源码目录建立构建目录,并cd进入构建目录

 view plain copy

$ mkdir build  

 view plain copy

$ cd build  

d.运行configure配置,make && sudo  make install

 view plain copy

$ ../configure –prefix=/opt/glibc-2.14  

$ make -j4   

$ sudo make install  

 password for ghui:   

4.临时修改环境变量

 view plain copy

$ export LD_LIBRARY_PATH=/opt/glibc-2.14/lib:$LD_LIBRARY_PATH  

 view plain copy

$ cd /var/VMdisks/cross/mingw32/bin/  

 view plain copy

$ ./qmake   

Usage: ./qmake     

QMake has two modes, one mode for generating project files based on  

some heuristics, and the other for generating makefiles. Normally you  

shouldn’t need to specify a mode, as makefile generation is the default  

mode for qmake, but you may use this to test qmake on an existing project  

…  

此时运行正常,问题解决。

By ghui

怎么解决安装linux软件的依赖问题

使用yum install命令安装,会自动安装依赖软件

利用yum安装软件(自动解决依赖关系)

YUM有以下特点:

1、可以同时配置多个资源库(Repository)

2、简洁的配置文件(/etc/yum.conf)

3、自动解决增加或删除rpm包时遇到的依赖衫岁性问题使用方便

4、YUM分为服务器端和客户端

搭建yum服务器:

1、挂载redhat5.5安装光盘。

2、安装vsftp软件。

3、解除挂载,然后重新挂载到/var/ftp/pub/下(客户端利用ftp下载软件包,通过yum命令安装ftp上的软晌岁件)

4、利用或谨睁vi修改/etc/yum.repos.d/rhel-debuginfo.repo文件,这个文件是客户端修改的文件,我直接在服务器修改了,用于填写yum服务器的地址和软件包ftp的位置。

5、下面以安装dns服务器软件 bind为例,如果不利用yum安装,需要解决依赖关系,比较麻烦。如下图:

6、上图可以看出,安装出错,需要首先安ind-9.3.6-4…..之后才能安ind-chroot-9.3,下面先安ind-9.3.6-4。

7、然后再安ind-chroot-9.3,如图所示可以正常安装了。

在Linux系统中,软件包的依赖关系让人很是头疼。如在安装Linux系统时,不是选择安装所有的软件包。在安装完Linux系统后,若再进行软件安装的话,就可能会遇到一些依赖关系的问题,如在安装PHP软件包时,系统就可能会提示一些错误信息。说需要其他的一些软件包的支持。其实类似的情况在Windows中也会遇到。如有时候安装一些应用软件可能对浏览器的版本会有要求或者要求操作系统的补丁达到SP2以上等等。不过在微软操作系统上这种软件依赖关系要比在Linux系统中少见的多,而且处理起来也方便一些。   那么Linux操作系统中如果遇到这种软件包依赖关系的话,该如何处理呢?在谈这个具体的解决措施之前,我先跟大家说说在哪些情况下容易出现软件包的依赖关系问题。  一是在操作系统安装的时候,没有选择全部的软件包。大部分时候出于安全或者其他方面的原因,Linux系统管理员往往不会选择安装全部的软件包。而只是安装一些运行相关服务所必要的软件包。但是有时候系统管理员可能并不清楚哪些软件包是必须要装的,否则后续的一些服务将无法启动;而那些软件包则是可选的。由于在系统安装的时候很难一下子弄清楚这些内容,故在Linux系统安装完毕后,再部署其他一些软件包的时候,就容易出现这个问题。  二是在Linux服务器上追加其他的一些应用服务时,容易出现类似的问题。如有一次企业需要使用一个Oracle数据库,我就在原先的文件服务器上安装Oracle数据库。但是在Linux操作系统上安装Oracle服务器是一个很头疼的问题,需要安装不少的软件包。而我一开始部署Linux文件服务器的时候又不知道后来需要安装Oracle数据库,故不少的软件包都没有装。而且后来发现,不少的软件包其实在Linux安装盘中还没有,需要自己到网上去下。所以,如果要在原先已经部署好的Linux服务器中追加一些应用服务时,很容易出现这个软件包的依赖问题。  其实解决这个软件包的依赖问题说简单也不简单,说复杂也不复杂。我下面总结了几个方法,各位若有需要的话可以借鉴一下。  一、根据错误提示信息在安装光盘中寻找。  在安装软件包时如果遇到软件依赖关系问题时,通常情况下系统都会提示相关的信息。如提示“libgd.so.1.8 is needey by php-4.2.2-17”等等。这就表示安装PHP程序时,需要先安装libgd.so软件包。当遇到这个问题时,我建议系统管理员可以根据这个提示信息,先从Linux系统的安装盘中查找一隐知下是否有这个软件包。  如上图所示,在Linux安装盘中的RPMS目录下面就存放着大量的软件包唤明。通常情况下,像上面的libgd.so等常见的软件包都可以从和携告这个光盘中找到。所以系统管理员根据系统的错误提示信息,就可以了解到安装某个软件之前先要安装那个软件包。然后从系统光盘中找到这个软件包,并进行安装即可。另外需要说明的是,向RedHat操作系统,如果采用的是CD安装盘,则其可能有很多张光盘。而这些软件包往往不是存储在一张CD光盘中的。不过可以肯定的是,每张光盘下都会有RPMS这个目录。当系统管理员不知道某个软件包存储在哪个盘中的话,则可以一张张的找过去。虽然比较麻烦一点,但是大部分情况下都会有收获的。  不过如果采用这个方法有一个限制。像安装Oracle这种大型的应用软件就不怎么适用。因为安装这种大型的软件本身就比较花费时间。如果等到安装失败之后再根据错误提示来安装软件包的话,则重复来重复去会浪费很多的时间,而且也会让系统产生很多的垃圾文件。为此除非是一些小型的软件包,否则的话,更好还是根据下面我要介绍的方法来做,以节省软件安装的时间。  二、参考官方的文档。  通常情况下,一些软件的官方文档会说明安装它们的软件需要哪些软件包。如在安装Oracle数据库时,就必须需要安装不少的软件包。到底需要安装哪些软件包,在Oracle的官方网站上都会有详细的说明。我在安装Oracle数据库时,就先安装这个说明,一一来验证Linux系统中是否安装了这些软件包。如果没有安装的话,就马上装上去。此时各位Linux系统管理员不要抱着侥幸心理,已经不安装不会有大问题,这是大错特错了。对于Oracle公司官方网站建议的软件包在Oracle数据库系统安装之前必须一五一十的安装上去。否则的话轻则导致数据库安装失败,重者的话会导致后续数据库运行不稳定。  其实不光是Oracle数据库系统,其他的一些应用软件对Linux系统都会有类似的要求。它们要求在安装它们的应用软件之前,Linux系统必须安装有某些软件包,否则的话安装就会失败。所以我建议各位Linux系统管理员,在安装这些软件之前,更好先到官方网站上去寻找类似的文档,然后对照文档的内容去验证Linux系统是否安装了这些软件包。如此的话就可以避免软件包依赖关系的问题。另外,在网络上也可以寻找到很多有用的价值。有些安装过这个软件的Linux系统管理员,会把自己安装过程中系统遇到的软件包依赖关系列举出来,会一一说明需要先安装哪些软件包。这些网络上的文档虽然其专业性可能没有官方提供的文档那么专业。但是对我们来说也具有很大的参考价值。  三、从专业网络上查询。  为了正确安装某些软件包,需要安装一些文件。可是有时候系统管理员可能根据系统的提示还不能够确定到底安装哪些软件包才会有这些文件。特别是对于一些不常用的软件包或者系统管理员之一次接触的软件包往往会遇到这种问题。此时,系统管理员就可以到一些专业的网站上去查询。这里我给大家介绍一个很不错的网站,即

。系统管理员只需要在这个网站搜索的地方输入需要的文件名字,如libgd.so,则搜索结果中就会显示需要安装哪个软件包才具有这个文件。找到这个软件包的名字之后,只需要从光盘或者网络上下载这个软件包进行安装即可。当然,在安装这些软件包的时候,可能还会遇到其他软件包依赖关系的问题。如安装php软件包需要libgd.so文件,而这个文件属于gb软件包。但是在安装gb软件包时,可能这个软件包跟其他软件包又具有依赖关系,又需要安装其他软件包才行。此时系统管理员就需要耐心的一一按顺序进行解决了。  可见大部分情况下,在遇到软件包依赖关系问题的时候,操作系统提供的文件名字与软件包名字都会有直接的联系。有可能文件的名字就是软件包的名字。但是有些时候文件的名字与软件包的名字会相差甚远。此时大部分系统管理员可能光凭文件名字无法找到对应的软件包。此时就需要借助笔者上面谈到的一些专业网站,去查询软件包的名字了。  另外我还有一个小建议。当系统管理员安装了某个软件之后,如果存在软件包之间的依赖关系,则更好能够拿本子或者通过其他手段记录下来。因为在以后的工作中很有可能还会需要安装这些软件。如此的话,在下次安装的时候就不用这么麻烦了。可以对照以前的笔记直接安装需要的软件包。毕竟在同一个地方摔倒多次不是什么光彩的事情。

一般制作yum仓库,可以解决。你在可以在网上搜索制作yum仓库的资料,做起来很简单的。

这里下载相竖察应的丛纤档软件渗乱啊

Linux下程序运行依赖库如何指定?

so文件内部有一个自己的名字派祥,可以和文尘洞搏件名不同,这个名字由链接器在link期间写入so

库文件

中。

你可以使用 readelf -a b.so | grep SONAME,颤裂来查看

这个内部名字不因为文件名变化而改变。

关于linux下依赖dll的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。


数据运维技术 » Linux上的动态链接库依赖问题 (linux下依赖dll)