Gcc Libtool根据显式路径（no-l选项）给出的静态库链接共享库

我想将静态库libyaml cpp中的所有符号拉入我正在构建libLHAPDF的共享库中，以避免后者的用户显式依赖。这不是我最喜欢的方式，但安装必备软件的困难在于对软件包的定期负面反馈。因此，我尝试使用如下自动生成规则构建共享库的相关部分：

libLHAPDFInfo_la_LDFLAGS = $(AM_LDFLAGS) \
  $(srcdir)/yamlcpp/yaml-cpp/libyaml-cpp.a

我特别想要这样的东西，而不是

libLHAPDFInfo_la_LDFLAGS = -L$(srcdir)/yamlcpp/yaml-cpp -lyaml-cpp \
  $(AM_LDFLAGS) 

因为系统的其他地方可能安装了libyaml cpp的共享lib版本，我不想使用它。在后一种情况下，奇数标志顺序是试图确保-lyaml cpp找到srcdir中内置的标志。。。是的，在这种情况下，它实际上是srcdir而不是builddir

但是，第一个版本给出了一个警告，我不希望出现：

*** Warning: Linking the shared library libLHAPDFInfo.la against the
*** static library ./yamlcpp/yaml-cpp/libyaml-cpp.a is not portable!

更重要的是，它实际上不起作用：如果我在生成的库上运行nm，我会看到未定义的符号：

$ nm src/.libs/libLHAPDFInfo.a | grep YAML
U _ZN11LHAPDF_YAML4NodeC1Ev
U _ZN11LHAPDF_YAML4NodeD1Ev
...

详细信息：libLHAPDFInfo.a是一个noinstltu库条目，用作构建最终共享库的中介。因此，当链接一个静态库与另一个静态库时，这甚至不起作用。为了避免符号冲突，捆绑版本被稍微修改了一下，将YAML名称空间重命名为LHAPDF_YAML：这不会改变任何事情，但我想我会提到它，以防这些符号名称对您来说很陌生

如果以-lyaml cpp方式使用第二种形式的链接标志，我将获得libLHAPDFInfo.a中的所有LHAPDF_YAML符号，然后将其放入共享库中。并且不再有任何关于使用-fPIC构建的静态库链接的不可移植性的警告，所以这样做是有效的。但是，如果在系统上也找到了共享libyaml cpp，那么无论-L/-L标志的顺序如何，都会使用它，这是我不想要的

关于如何确保使用特定路径上的库版本，同时正确复制符号并避免libtool警告，有何建议

---

编辑：已经说过我可以通过-lyaml cpp标志将符号从libyaml cpp.a复制到libLHAPDFInfo.a中，经过多次迭代后，我再也无法通过nm使用这种方法来显示预期的符号。查看libtool在生成libLHAPDFInfo.a时执行的ar/ranlib命令，-l参数似乎被完全删除了。所以我不知道它是怎么工作的。。。据我所知，这不是libtool支持的模式，也不是文档化的模式。最后，作为构建的一部分，我将libyaml cpp重命名为liblhapdf yaml cpp.a，因为不应意外找到具有该名称的库，并将其链接到最终的共享liblhapdf.so，而不是静态便利库。没有我希望的那么整洁-我希望将所有yaml cpp依赖处理隔离到一个方便库的构建中，依靠文件副本来消除库查找的歧义是不令人满意的-但它是有效的。

>但是如果在系统上也找到共享的libyaml cpp，不管-L/-L标志如何，都会使用它ordering@ldav1s你的评论有什么遗漏吗？或者你的意思是这就是libtool的行为：有什么参考吗？最后，我通过插入本机make规则来解决这个问题，将绑定的静态库重命名为保证唯一的名称，并将其链接到最终的共享库而不是静态库。但是如果a使用绑定的静态库的abs路径，b将其符号拉入便利库，那就太好了。由-L插入的路径在任何默认目录之前都会被搜索，因此libLHAPDFInfo_la_LDFLAGS的第二个定义的一些变体应该可以工作。啊哈，感谢您的解释！在系统上意外发现的一个可能在AMldflags中，但需要注意。无论如何，在构建静态libs时，至少为了方便libs，LDFLAGS中的-l参数似乎被libtool忽略了，所以必须做一些其他的事情。方便lib不是最后的链接步骤，因此-l参数被丢弃在那里也就不足为奇了。