我正在尝试构建依赖于某些静态库的自定义NS3模块。这个静态库依赖于NS3模块。
平台：Ubuntu 16.04 x64 工具链：GCC 5.4.0
我将我的自定义NS3模块称为 mymodule
我将引用 mymodule 所依赖的库作为 mylib
我将引用与 mymodule 和 mylib 链接的程序作为 myprog
def build(bld):
module = bld.create_ns3_module('mymodule', ['network'])
module.features = 'c cxx cxxstlib ns3module'
module.source = [
'model/mymodule.cc' ]
# Make a dependency to some other static lib:
bld.env.INCLUDES_MYLIB = [ "some/include/path" ]
bld.env.LIB_MYLIB = ['mylib']
bld.env.LIBPATH_MYLIB = [ "some/path" ]
module.use.append('MYLIB')
# Create a program which uses mymodule
p = bld.create_ns3_program('myprog', ['core', 'mymodule'])
p.source = 'prog.cpp'
headers = bld(features='ns3header')
headers.module = 'mymodule'
headers.source = ['model/mymodule.h']
mymodule ：
./waf build当我-Wl,--start-group
-lns3.26-mymodule-debug -lmylib -Wl,--end-group失败时：LD无法链接 myprog ，因为 mylib 具有未解析的符号。这种失败实际上是预期的，因为 mylib 和 mymodule 是相互依赖的，应该以非标准方式链接。
解决方法：
如果我手工构建 myprog 并使用ar -M，那么链接就完全正常并按预期工作。
如果我手动组合两个静态库（使用./waf build脚本）然后运行wscript它也可以正常工作。
问题：如何将上述解决方法之一集成到java.util.concurrent.BlockingQueue？
答案 0 :(得分：1)
它看起来像静态库包含顺序的已知问题。由于这个问题，waf 1.9中的行为发生了变化。
一种解决方法可能是使用linkflags的{{1}}属性。您应该更喜欢使用program和STLIB_MYLIB，因为mylib是静态的。在waf 1.9中，正确的lib顺序就足够了。
无论如何，使用-v来查看waf生成的命令行，它可能有所帮助！