在Debian软件包中支持多个Boost版本

我正试图为我的一个项目创建一个debian包，但在boost版本支持方面遇到了问题

我确实研究过这个问题。这是类似的，但提供的解决方案（构建取决于）并不真正适用于我，因为我正在制作一个二进制安装程序

基本上，我安装的库和可执行文件总是链接到libboost_u2;（component）.so.1.46，而不是符号链接库libboost_2;（component）.so。让我的debian安装程序只能由使用我的确切boost版本的人使用。我正在使用CPack制作debian包，我的depends行如下所示：

SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libboost-dev (>= 1.46),
                                  libboost-thread-dev (>= 1.46),
                                  libboost-signals-dev (>= 1.46),
                                  libboost-system-dev (>= 1.46), 
                                  libboost-filesystem-dev (>= 1.46),
                                  libboost-python-dev (>= 1.46), ..." )

---

我是否需要为上述平台上的每个平台或该平台的boost版本构建单独的安装程序？

虽然我理解您希望创建一个可与所有boost版本兼容的软件包的意图，但您确实需要问问自己这是否真的可行

.so

版本（例如

.so.1.46

vs

.so.1.48

）的概念实际上是表示库接口（ABI），它基本上表示库不兼容

因此，针对

libboost\u-foo.so.1.46

的应用程序链接实际上不太可能与

libboost\u-foo.so.1.48

一起工作。 很可能是应用程序所需的符号突然消失了（因此应用程序将拒绝启动）。更糟糕的是，符号的含义可能在不同版本之间发生了变化，导致难以跟踪未定义的行为

这就是为什么每当你链接到

libfoo.so

，二进制文件都会链接到

libfoo.so.1

（或者

libfoo.so

真正指向的地方）

现在，包名必须为任何不兼容的ABI更改而更改。这基本上允许用户同时安装同一库的两个版本（例如boost-1.46和boost-1.49）

如果您的目标是特定版本的Debian，则可以确保库的特定版本可用。e、 g.在Debian/wheezy上，您将获得boost-1.49。 因此，如果您提供Debian/wheezy软件包，您只需要链接boost-1.49即可。 这也是发行版如此出色的原因之一：它可以保证所有需要的lbiraries都可用

这还意味着，在多个Debian版本中，同一应用程序可以有不同的包版本，即使没有“上游”版本：由于依赖项的升级（涉及soname更改），包必须重新生成

因此，总结如下：

• 链接到实际库版本是保持系统正常运行的一项功能

• debian允许同时安装同一库的多个版本

您的问题的解决方案：

• 为任何依赖项的每个soname版本提供二进制软件包

---

为每个debian发行版提供软件包将使这一点看起来不那么麻烦（因为每个发行版只有一组固定的库）。

您可以尝试静态链接boost软件包：

---

设置（Boost\u USE\u STATIC\u LIBS ON）

感谢您的回复。奇怪的是，我的应用程序实际上与boost 1.46、1.48和1.49一样工作，没有任何问题。看起来我的选择是（a）根据我想要支持的Ubuntu版本构建一个新的debian安装程序，或者（b）在每台机器上安装boost 1.46，即使它有一个更新的boost版本。我认为（a）听起来是一个更好的选择，可能值得这么麻烦。按现状工作是什么意思？您是否可以重新编译任何版本的boost应用程序，或者即使您将

libboost\u foo.so.1.46.0

与

libboost\u foo.s.1.49.0

进行交换，它是否仍能继续工作？无论如何，如果它真的有效，那只是运气（这取决于你从库中真正导入了多少符号）。无论如何，你的解决方案（a）确实是一条路（尽管我不知道在这个游戏中，ubuntu在哪里取代了debian），我的意思是人们已经编译、链接，并在几个版本的boost上运行我的源代码，没有问题。我认为我很幸运地使用了没有收到API更新的boost组件。正如你所说，出于这个原因，我将尝试使用（a）；这与ABI兼容性没有直接关系。（使用一些宏很容易获得完全不同的API（源代码中的符号）和ABI（链接器级别的符号）