使用 Autotools 和多个构建目录创建单个静态（方便？）库
我正在维护一个库项目，该项目构建一个“前端”库和多个“后端”库。该项目使用 Autotools 套件（我正在学习并发现我们项目的实现需要维护），包括 Libtool。作为共享库，一切都运行得很好。我们有一位使用该库的应用程序开发人员，并且更喜欢使用静态库进行构建，因为他可以轻松地在多个平台上分发软件（我不想争论他的动机）。
他告诉我，之前他能够使用我们的构建系统构建一个大型静态库，但现在不能了。我无法准确追踪这种情况发生的时间，但怀疑它可能与两个变化之一有关。第一个更改是删除捆绑的 libtool 源目录。第二个是将后端库放入 /usr/local/lib/project 中，而不是像以前那样将它们分散在 /usr/local/lib （默认位置）中。
我无法学习的是如何将前端库与后端组合成 /usr/local/lib 下的单个便利库，并在 Autotools 框架内执行此操作。这似乎是可能的，但我还没有找到可以学习的例子。
顺便说一句，这些项目构建了几个实用程序作为我们测试套件的一部分。我使用 --disable-shared 选项运行配置，然后进行 make，实用程序静态链接到项目库。现在我的任务是让第三方应用程序可以使用此功能。
I am maintaining a library project that builds a "front end" library and multiple "back end" libraries. The project utilizes the Autotools suite (which I am learning and finding our project's implementation is in need of maintenance) including Libtool. As shared libraries it all works very well. We have an application developer that uses the library and prefers to build using static libraries for his ease of software distribution across multiple platforms (I don't wish to debate his motives).
He has told me that at a previous point he was able to build a single large static library using our build system but is no longer able to. I have been unable to trace exactly when this occurred but suspect that it may be related to one of two changes. The first change was removal of a bundled libtool source directory. The second was placing the backend libraries into /usr/local/lib/project rather than scattering them about as before in /usr/local/lib (default locations).
What I have been unable to learn is how to combine the frontend library with the backends into a single convenience library under /usr/local/lib and do so within the Autotools framework. This seems to be possible but I've not found an example to learn from.
As an aside, the projects builds several utilities as part of our test suite. I ran configure with the --disable-shared option, then make, and the utilities are statically linked to the project library. Now my quest is to make this functionality available to third party applications.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
用 Libtool 的行话来说，便利库是指未安装的库。必须使用
noinst_前缀向 Automake 声明它。当您从多个便利库构建库 L 时：所有便利库都会聚集起来构建将安装的单个库 L。无论 L 是共享库还是静态库，都会发生这种情况。
我的猜测是您有第三个更改：也许过去您所有的后端库都是方便的（即
noinst_）库，因此您实际上只安装了一个.so并且最终是一个.a；但在某些时候，决定自行安装所有这些后端库（即，将noinst_更改为pkglib_或类似的），因此这些库不再是便利库，并且它们不再包含在前端中。请注意，如果已安装的后端库仍列为前端库的
_LIBADD，则 Libtool 仍会记录此依赖关系。每当您链接到已安装的frontend.la文件时（这需要您使用libtool进行链接，即使作为库的用户也是如此），Libtool 也应该包含后端库，无论frontend.la是编译为静态库还是共享库。PS：如果您的后端库实际上是由前端加载的 Libtool 模块（又名插件），那么情况会略有不同。
In Libtool's jargon a convenience library is a library that is not installed. It must be declared to Automake with the
noinst_prefix.When you build a library L out of multiple convenience libraries: all the convenience libraries are gathered to build a single library L that will be installed. This happens regardless of whether L is a shared library or a static library.
My guess is that you have a third change: maybe in the past all your backend libraries were convenience (i.e.,
noinst_) libraries so you were effectivelly installing only one.soand one.aeventually; yet at some point it was decided to install all these backend libraries on their own (i.e., change thenoinst_topkglib_or similar), therefore these libraries stopped being convenience libraries and they are no longer included in the frontend.Note that if the installed backend libraries are still listed as an
_LIBADDfor the frontend library, this dependency is still recorded by Libtool. Whenever you link to the installedfrontend.lafile (this requires you uselibtoolfor linking, even as a user of the library), Libtool should include the backend libraries as well, regardless of whetherfrontend.lawas compiled as a static or shared library.PS: The matter would be slightly different if your backend libraries are actually Libtool modules (a.k.a. plugins) that are dlopened by the frontend.