共享库或dylib中未定义符号的处理是什么？

Question

我有一个用于Linux的Makefile,我将其移植到达尔文.makefile接受一堆.o文件并将它们链接到一个.so共享对象中.好吧,所以我想(我错了吗？)达尔文最好的模拟是dylib.所以我将-shared标志更改为-dynamiclib.

现在我连接到dylib的代码依赖于许多外部库.当我尝试构建dylib时,我得到错误,说有未定义的引用.但是Linux Makefile没有在创建.so文件的构建步骤中指定任何-lwhatever或-L/path/whatever选项.嗯？这是因为当您创建ELF .so文件时,默认情况下它会保留未解析的外部引用,然后在加载共享库时递归加载您正在加载的共享库所依赖的共享库？如果共享库依赖于.a或.o文件,您是否必须将它们静态链接到共享库中,否则您无法在运行时链接？除非引用也是可动态加载的库,否则如何在运行时加载的库中使用未定义的引用？

无论如何,如果我指定

-undefined suppress -flat_namespace

在创建共享库时,它不需要我添加-l和-L选项.但我仍然不明白这最终会如何发挥作用.

Answer 1

该主题还讨论了这个问题.我认为关键点在于,为了获得类似Linux的链接行为,您需要指定"-undefined dynamic_lookup"标志.默认情况下,如果动态库中存在任何未定义的引用,Darwin链接器将引发错误.您还可以使用-U在每个符号的基础上设置此行为.请参阅'man ld'以供参考.

Answer 2

使用libtool。

libtool -dynamic -multiply_defined suppress -install_name `basename ../../../../rlp/lib/universal-darwin9-gcc40/libbtutils.dylib` -o ../../../../rlp/lib/universal-darwin9-gcc40/libbtutils.dylib   ../../../../rlp/lib/universal-darwin9-gcc40/libbtd.a ../../../../rlp/lib/universal-darwin9-gcc40/libbttrie.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtkey.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtunit.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtutilities.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtopts.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtxcode.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtprops.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtxml.a ../../../../rlp/lib/universal-darwin9-gcc40/libbttake3.a ../../../../rlp/lib/universal-darwin9-gcc40/libbttake5.a ../../../../rlp/lib/universal-darwin9-gcc40/libbtac.a  -lstdc++.6 -lgcc_s.10.4 ../../../../build_system/lib/universal-darwin9-gcc40/libgcc.a -lSystem -lSystemStubs`