在一个基于 autotools 的项目中，我捆绑了另一个小型静态库，并以安全的方式将其链接到我的最终共享库中(静态是使用 -fPIC 等构建的)最终应该没有任何证据内部静态库的存在作为构建过程的一部分，其符号都应该“复制”到共享库中。
最后一个条件肯定满足，用nm检查，并使用 ldd在共享库上显示没有“需要”的 ELF 部分对静态库的依赖。但是 libtool 的 .la存档文件是另一回事:dependency_libs变量在那里拿起一个 -lmy-secret-temp-lib (名称已更改以保护无辜者)条目随后会破坏任何基于 libtool 的项目，该项目试图针对最终库进行构建，因为永远无法满足该依赖项。非 libtool 项目当然很好，因为在 .la 中除了 libtool 之外什么都没有。文件。
有没有办法告诉 libtool 不向 dependency_libs 添加库？变量在其 .la当文件包含在 xxxx_la_LIBADD 中时多变的？也许有一些前后参数，比如 -flibtool_ignore -lmy-secret-lib -flibtool_payattention允许开发人员告诉 libtool 停止妨碍？能够告诉 autotools/libtool 不制作/安装 .la 会很好。文件，但这似乎不是一种选择!
最佳答案
这是我们为后代找到的最佳解决方案:
似乎没有非常巧妙的方法可以让它发挥作用。我发现最好的方法是避免 -L和 -l像这样“内部”链接时标记，而不是直接放置 $(builddir)/extralib/libmy-secret-lib.a在最终共享库的 LDFLAGS/LIBADD 变量中。
不幸的是，这会产生一个关于不可移植性的 libtool 警告，并且需要使用 -fPIC 构建“手工制作的便利库” - 即使它是这样构建的并且是完全便携的。 ...LIBTOOLFLAGS = --silent遗憾的是，这还不足以隐藏那个哭狼警告，但结果是好的:需要的符号被复制到最终库中，dependency_libs干净，不需要黑客(像这样: https://gitorious.org/libguestfs/libguestfs/source/c46bedf925cd9c6c9a9cbaee115358fd1dffcbfe:libtool-kill-dependency_libs.sh )。
关于static-libraries - 与 libtool 静态链接，无需修改 .la 文件中的 dependency_libs，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21407902/