我有一个程序希望在我用环境变量指定的目录的子目录中查找库文件。是否有可能在我指定的目录中放置一个忽略所附加的第一个子目录的路径?我的意思是。
我的文件夹结构
/usr/lib64/[All the library files]程序看
$MAGICK_HOME/lib/[All the library files]在那里我可以操纵$MAGICK_HOME。
因此,如果我设置MAGICK_HOME=/usr,它将看到/usr/lib/[library files],这是错误的。如果我设置MAGICK_HOME=/usr/lib64,它将看到/usr/lib/lib64/[library files],这也是错误的。
如果相反,我可以忽略前缀路径中指定的最后一个目录,方法是以../开头后缀,以便从最外层的目录返回。我可以把什么作为我的MAGICK_HOME来指定正确的目录?
发布于 2021-03-03 16:56:01
以下是三种令人感兴趣的情况:
/usr/lib64的库,但您希望将其读入$MAGICK_HOME/lib:的库中。
如果要编译应用程序,可以添加一些RPATH或RUNPATH规则,以便二进制文件在$ORIGIN/../lib64中搜索libs。否则,可以在启动二进制文件的shell脚本中将$MAGICK_HOME/lib添加到$LD_LIBRARY_PATH,以便动态链接器搜索该路径以查找二进制文件,也可以使用ldconfig向/etc/ld.so.cache添加特定的库。
$MAGICK_HOME/lib的库而不是/usr/lib64当ld.so动态链接时,它搜索:
DT_RPATH字段(如果DT_RUNPATH不存在)。这通常是一个绝对路径,或相对于二进制文件($ORIGIN)位置的路径。我不认为像$MAGICK_HOME这样的环境变量能够影响它。$LD_LIBRARY_PATH环境变量(除非在安全执行模式下运行)DT_RUNPATH字段在ELF-二进制文件中编译(类似于上面的DT_RPATH )。/etc/ld.so.cache,它包含已编译的候选共享对象列表。/lib和/usr/lib的默认路径。在某些架构中,64位共享对象的默认路径是/lib64和/usr/lib64。如果二进制文件与-z nodeflib链接器选项链接,则跳过此步骤。由于/usr/lib64可能处于默认路径,所以我怀疑程序启动时正在操作$LD_LIBRARY_PATH,或者在安装期间使用ldconfig将库添加到/etc/ld.so.cache中。这将导致首先找到$MAGICK_HOME/lib库。如果您可以阻止它做这些事情,那么它应该回到/usr/lib64。
您可以使用readelf查看它是为特定的DT_RPATH或DT_RUNPATH编译的,但我不认为是这样的,因为环境变量似乎会影响链接,并且这些选项不能(AFAIK)受到环境的影响。
/usr/lib64中的库
如果问题不是加载错误的二进制文件,而是没有加载任何二进制文件,那么可能是/usr/lib64不在您的默认路径中。我们需要了解您的发行版和架构,以便在这种情况下有进一步的帮助。
https://unix.stackexchange.com/questions/637375
复制相似问题