4

我正在尝试构建和运行我正在处理的项目。我继续建造，一切都很棒，没有任何错误。然后，当我尝试运行可执行文件时，我收到一条错误消息，指出无法找到某些动态库依赖项：

dyld: Library not loaded: libgpr.dylib
  Referenced from: ./test-exec
  Reason: image not found
Trace/BPT trap: 5

有趣的。报告什么otool -l？

... snip ...
Load command 11
       cmd LC_MAIN
   cmdsize 24
  entryoff 1247184
 stacksize 0
Load command 12
          cmd LC_LOAD_DYLIB
      cmdsize 104
         name /abs/path/to/libprotobuf.10.dylib (offset 24) <--- The same path as passed to the linker
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 11.0.0
compatibility version 11.0.0
Load command 13
          cmd LC_LOAD_DYLIB
      cmdsize 40
         name libgpr.dylib (offset 24)     <--- Note the local path
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 0.0.0
compatibility version 0.0.0

是什么赋予了？我的构建调用是（经过一些清理之后），由 CMake 发出：

编译（为了可读性而换行）

cd /path/to/project && /path/to/c++ 
   -Wno-inconsistent-missing-override -g -fPIE 
-I/path/to/project -I/googletest/headers 
-I/googlemock/headers 
-I/path/to/project/usr/include 
-I/include 
-I/path/to/jni/Contents/Home/include
-I/path/to/jni/Home/include/darwin
-std=gnu++11 -o test-exec.o -c
/path/to/project/test-exec.cc

关联：

cd /path/to/project && /usr/local/Cellar/cmake/3.2.2/bin/cmake -E cmake_link_script CMakeFiles/test-exec.dir/link.txt --verbose=1
/path/to/c++   
-Wno-inconsistent-missing-override -g 
-Wl,-search_paths_first
-Wl,-headerpad_max_install_names  
test-exec.o  -o test-exec
/path/to/libprotobuf.dylib 
/path/to/libgpr.dylib
/path/to/libgrpc.dylib
/path/to/libgrpc++.dylib
../../dep1.a
../../dep2.a
/path/to/libgmock.a
/path/to/libgmock_main.a 
/path/to/libgtest_main.a

据我所知，在链接阶段，两者libprotobuf.dylib都libgpr.dylib作为绝对路径传入。怎么会libprotobuf.dylib被绝对路径加载而不是libgpr.dylib？

对于它的价值，设置DYLD_LIBRARY_PATH使它工作，但我不想设置它或导出它。我已经设置了我的仓库来构建所有依赖项并将它们放入一个特定的目录中，它应该只是克隆和构建。

我的编译器版本是：

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ --version
Apple LLVM version 7.0.0 (clang-700.0.72)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
4

1 回答 1

1

我最近遇到了这个问题。install_name_tool在构建 dylib 后使用解决了问题；但是，我正在使用的 clang 版本接受一个-install_name参数，该参数允许我重命名我正在构建的 dylib（我使用-install_name @rpath/<name>.dylib）。otool -D <name>.dylib确认更正的名称。一旦主程序与这个新建的 dylib 链接，otool -l <exe>显示正确更新的路径（@rpath/<name>.dylib在我的情况下），并且在运行时正确找到了 dylib。

于 2021-09-30T20:13:14.100 回答