对Boost库的依赖没有完整的路径 [英] Dependencies on boost library don't have full path
问题描述
我成功建立了动态库，并且依赖于使用自定义前缀(./b2 install --prefix=PREFIX)构建和安装的boost库.但是，当我在库上运行otool -L时，会得到如下输出:
I have my dynamic library built successfully with dependencies on boost libraries which were built and installed with custom prefix (./b2 install --prefix=PREFIX). However, when I run otool -L on my library I get output like this:
...
libboost_regex.dylib (compatibility version 0.0.0, current version 0.0.0)
libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
...
与其他依赖项不同，
在没有这些boost库的完整路径的情况下被呈现.当我的库由应用程序加载时，这会导致运行时错误.
我知道可以使用install_name_tool手动解决此问题.但是，我试图弄清楚，为什么它仅在boost库中发生，而在我的lib所依赖的其他依赖项中却没有发生?
Which is, unlike other dependencies, presented without full path towards these boost libraries. This results in runtime errors when my lib is loaded by apps.
I know that one can use install_name_tool to manually fix this problem. However, I'm trying to figure out, why does it happen only for boost libraries and does not happen to other dependencies my lib depends on?
编辑
我被要求给出一个构建命令的例子，但是像往常一样，现实生活"的例子要复杂一些.
就我而言，有一个依赖于boost的库libA.dylib.然后，有我的库libMy.dylib，它也依赖于libA.dylib和boost.在执行简单库存在检查(类似于AC_CHECK_LIB的自定义测试程序)时，在configure步骤期间会出现问题.此检查尝试构建一个与libA.dylib链接的小型测试程序，以证明libA.dylib的可用性，但该程序失败-由于无法找到增强库的错误.当然，找不到它们是因为otool -L libA.dylib在没有完整路径的情况下为我提供了增强库.
I've been asked to give an example of build command, but like usual, "the real life" example is a bit more complicated.
In my case, there is a library libA.dylib which depends on boost. Then, there's my library libMy.dylib which depends on libA.dylib and boost as well. The problem arises during configure step, when simple library existence check is performed (custom test program similar to AC_CHECK_LIB). This check tries to build a little test program which is linked against libA.dylib in order to prove availability of libA.dylib and it fails - due to the error of not being able to find boost libraries. Of course it wouldn't find them because otool -L libA.dylib gives me boost libs without full path.
推荐答案
要回答这个问题:
为什么只在boost库中发生这种情况，而我的lib所依赖的其他依赖项却没有发生?"
To answer the question:
"why does it happen only for boost libraries and does not happen to other dependencies my lib depends on?"
技术原因是Boost构建系统(bjam)将库的安装名称明确分配为仅文件名.可以使用 -install_name 编译器选项在内部进行此操作.
出于其背后的原理，我不能代表Boost开发人员，所以我只能推测(这是一种不良的投资形式):在库中对本地安装路径进行硬编码只是延迟了找不到库"的工作.分发时间的运行时错误，因此他们可能只希望您在开发时间之内正确解决它. (或者这只是他们不想花费更多时间进行返工的遗留行为；)
The technical reason is that Boost build system (bjam) is explicitly assigning the install name of the library to be only the file name. It could internally be doing that using the -install_name compiler option.
For the rationale behind it, I cannot speak for the Boost developers, so I could only speculate (which is a poor form of investment): hardcoding the local installation path in a library is only delaying the "library not found" runtime error to the distribution time, so they could just want you to address it properly as soon as development time. (Or it could just be a legacy behaviour they did not want to invest more time to rework ;)
让我们假设您的动态库(取决于Boost)被命名为myLib.正如您在问题中已经指出的那样，您可以很好地更改记录在myLib:
Let's imagine your dynamic library (which depends on Boost) is named myLib. As you already pointed out in your question, you could very well change the install name for the Boost libs that is recorded in myLib:
install_name_tool myLib -change libboost_regex.dylib /full/path/to/libboost_regex.dylib
另一种方法是更改Boost库本身的安装名称:
An alternative is to change the install name of the Boost libraries themselves:
install_name_tool libboost_regex.dylib -id $new_name
使用这种方法，当您根据修改后的libboost_regex.dylib
With this approach, the install name $new_name will now be recorded in myLib when you build it against the modified libboost_regex.dylib
您知道必须确定要赋予$ new_name的值.当然，它可能是该库的完整路径，因此Boost库将表现为您的其他依赖项.
You know have to decide which value to give to $new_name. It could of course be the full path to the library, and this way Boost libraries will behave as your other dependencies.
An alternative -- more easily amenable to distribution -- is using RPath. (RPath based install names put the burden on the depender to find its dependency: the depender stores a list of path that it will try to replace "@rpath" with) :
install_name_tool libboost_regex.dylib -id @rpath/libboost_regex.dylib #assign a rpath dependant install name to a boost library
install_name_tool myLib -add_rpath $a_rpath_prefix # adds a candidate to substitute @rpath with, stored in myLib
$a_rpath_prefix可能是包含Boost库的文件夹的路径，它将在您的开发环境中很好地工作.并且，如果有一天需要分发库，则可以将Boost依赖项嵌入相对路径(或OS X捆绑软件)中，并添加遵循该相对路径的RPath值.
$a_rpath_prefix could be the path to the folder containing your Boost libraries, which will work well on your development environment. And if one day you need to distribute your library, you could embed the Boost dependencies in a relative path (or in an OS X Bundle), and add an RPath value that will follow this relative path.
对于您描述的无法定位Boost的自动检查的特定情况，您可以使用上面建议的替代解决方案来解决.它将更改Boost库的安装名称，该名称存储在库本身中(因此将被复制到libA.dylib中):
For the specific case you describe of an automatic check that cannot locate Boost, you can probably solve it with the alternative solution proposed above. It changes the install name of the Boost library which is stored in the library itself (and thus will be copied into libA.dylib):
install_name_tool libboost_regex.dylib -id /full/path/to/libboost_regex.dylib
在此特定用例中，甚至更简单的解决方案是用包含Boost库的目录的路径填充DYLD_FALLBACK_LIBRARY_PATH.动态链接器将在这些目录中查找库，因此它将在其中找到boost库.在将要运行构建检查的终端中:
In this specific use case, an even simpler solution could be to populate the DYLD_FALLBACK_LIBRARY_PATH with the path to the directory containing your Boost library. The dynamic linker will look in those directories for libraries, so it will find the boost libraries there. In the terminal in which the build check will be run:
export DYLD_FALLBACK_LIBRARY_PATH=/full/path/to/;$DYLD_FALLBACK_LIBRARY_PATH
这篇关于对Boost库的依赖没有完整的路径的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
