【问题标题】:proper handling of plugins (modules) in autotoos/libtool在 autotoos/libtool 中正确处理插件(模块)
【发布时间】:2016-10-20 17:14:41
【问题描述】:

我有一个生成静态库L的项目。L的某些功能可以加载一些插件M(使用dlopen("libmmmm.so"):M是共享库(模块))。

测试L的module_load()函数的测试T由主测试T(L静态链接)和插件M组成,用于测试其在T+L中的加载。

测试是安装的一部分(已定义 testdir)。

下面是测试 T 目录中的 Makefile.am(构建 T 和 M):

#the test program linked with the static lib L:   
#(the tests are distributed as well, hence the test_* prefix)                                  
test_PROGRAMS = tttt                                       
tttt_SOURCES = tttt.c
tttt_LDADD = llll.la

#the module to be loaded by the T+L test:                                                     
lib_LTLIBRARIES = libmmmm.la                                        
libmmmm_la_SOURCES = mmmm.c                                 
libmmmm_la_LDFLAGS = $(AM_LDFLAGS) -module -shared  

问题在于可以找到模块的路径: 测试工作(即找到 libmmmm.so)进行检查。但树外 (VPATH) 构建失败(未找到共享库)。

所以问题: 它应该如何工作? libtool 必须设置类似 LD_LIBRARY_PATH 的东西,我猜,因为dlopen() 永远不会理解*.la 包装器...

那么它有什么作用,我该如何解决这个问题,以便它一直工作,即进行检查,从树构建,进行 distcheck... 将搜索路径硬编码到 .libs 目录中感觉不太便携:我们使用自动工具,因为我们针对许多不同的平台。

PS:我知道由于“-module”选项,M的“lib”前缀可以省略

【问题讨论】:

  • @Diego 的建议是可行的方法。如果您的软件是使用libtool 构建的,则libltdl 不受 GPL 约束。它是可移植的,如果特定平台不提供,它会尝试模拟功能。 automake 手册中简要提到了模块。有关automakelibltdl 的更详细概述,请参阅libtool 手册。

标签: shared-libraries autotools libtool


【解决方案1】:

您可以使用 libltdl 来处理它,它确实理解 .la 文件,并且可以修复加载,但它不是 100% 相同的 API。

恐怕在这种情况下,您将不得不编写自己的包装脚本来设置LD_LIBRARY_PATH

【讨论】:

  • 实际上@Diego 的建议仍然存在问题:在链接库 L 时得到:“未定义引用 `lt__PROGRAM__LTX_preloaded_symbols'”。看起来 autools 在链接 L 时已经想知道 -dlopen 选项!但只有测试 T 知道!所以我现在在 tttt_LDAD 行上有“-dlopen mmmm.la”选项...构建 LIB 时可以使用 libltdl 吗? (即在知道要加载的模块之前)。
  • 但是ldl lib有一个叫lt_libltdl_LTX_preloaded_symbols的符号...这应该和lt__PROGRAM__LTX_preloaded_symbols一样???
猜你喜欢
  • 2016-03-19
  • 1970-01-01
  • 2015-12-30
  • 2016-07-19
  • 2016-03-04
  • 1970-01-01
  • 1970-01-01
  • 2010-12-27
  • 2021-12-31
相关资源
最近更新 更多