大佬教程收集整理的这篇文章主要介绍了c – 在基于libtool的项目中使用-rpath和$ORIGIN？，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
>构建外部项目：
./configure --prefix=$HOME/blah --etCETera && make && make install
>构建我自己的项目,该项目在运行时依赖于外部项目的共享库和可执行文件：
gcc -I$HOME/blah/include -L$HOME/blah/lib -o $HOME/blah/bin/program
>将所有内容打包成一个“本地化”tarball …也就是说,虽然我在构建主机上有$HOME / blah中的所有内容,但我希望能够将tarball提取到任意目录(在其他主机上),而不必与我的环境相比.目的是允许我的项目的多个版本并排共存,没有任何令人讨厌的“异花授粉”.
我知道我可以为我的项目使用-rpath’$ORIGIN /../ lib’来确保在运行时始终加载正确的共享库.但是,似乎libtool坚持根据$HOME / blah / lib的确切路径分配自己的-rpath设置,如果我碰巧将所有内容解压缩到另一个目录(例如,$HOME / blah),它会中断. 2011-06-02).
有没有解决这个限制的方法？我在这个主题上看到了rather lengthy rpath discussion between debian and libtool folks,但是除了“我们不同意”之外,它还有点陈旧和不确定.
chrpath或者一些后处理脚本听起来像是一个可行的选项. (它可以通过您最喜欢的包管理器在一堆发行版中找到.)
它不需要修补libtool,这是一个加IMO.
请注意,它有一些限制：如果新rpath比原始rpath更短(或相同),则只能保存新rpath.
另一个(实用的)选项是删除rpath(chrpath可以这样做),并且只有一个包装器脚本可以将LD_LIBRARY_PATH设置为应用程序所需的任何内容.这也有可能稍微便于移植(如果你处理其他共享库路径环境变量,那么一些操作系统有).
以上是大佬教程为你收集整理的c – 在基于libtool的项目中使用-rpath和$ORIGIN？全部内容，希望文章能够帮你解决c – 在基于libtool的项目中使用-rpath和$ORIGIN？所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。