未解决的对 boost::program_options::options_description::options_description 的引用答案

【问题标题】：unresolved reference to boost::program_options::options_description::options_description未解决的对 boost::program_options::options_description::options_description 的引用
【发布时间】：2020-09-08 09:58:57
【问题描述】：

首先我知道有几个类似的帖子，但我还是要问。 Debian "Buster" 和 Boost 1.67 软件包中的 boost program_options::options_description 是否存在已知问题？

我的代码是在 Debian 7 中开发的，系统升级到 8.3，然后是 8.11，现在使用 Boost 1.55。

代码构建并运行。现在使用 Boost 1.67 将系统升级到 Debian Buster 并获取未解决的对 options_description(const std::string& , unsigned int, unsigned int) 引用以及其他几个 program_options 函数的链接错误。所有未解决的，除了 options_description，都来自 boost 调用另一个 boost 函数，所以甚至没有直接从我的代码中调用。 boost_program_options 在链接行中。我不是新手，了解链接顺序，这与链接顺序无关。我将尝试获取 boost 和构建的源代码，看看它是否有效，如果没有，我将从头开始构建一个系统并针对它进行测试。由于这一切都在一个封闭的网络上，只是说尝试更新版本的 boost 或 Debian 不是一个选项，因为我有合同义务只使用 Debian "Buster" 和 Boost 1.67 作为最新版本，所以如果包不可用（更新) 在 Buster，这是不可能的，因为没有起草新合同并通过可能需要几个月的批准。

那么就这个问题而言，Buster 中的 Boost 开箱即用版本是否存在问题？

【问题讨论】：

尝试添加代码示例，但插入时不断出错。
仔细检查您的链接错误。我认为，在代码的某个地方应该有一些对旧版本的 boost 的引用。换句话说，您使用 boost 1.67 的新标头，但使用 1.55 的旧库。
旧库似乎已通过 apt-get purge libboost* 删除
检查您的链接错误。确保您有正确的引用来提升库。
确切错误是“未解决对 boost::program_options::options_description::options_description(const std::string&, unsigned int, unsigned int) 的引用”所有库都是 1.67.0

标签： c++11 boost debian-buster

【解决方案1】：

我认为 Buster 中的包不会有问题。

我最好的选择是要么

您正在将旧对象与新库重新链接 - 它们不匹配（您是否进行了完整的清理，例如以消除这种可能性？）。

通常构建系统不做完整的头文件依赖，所以构建系统可能不会注意到 boost headers 发生了变化，要求重建对象。
如果这不能解释，则包含路径上可能存在另一个版本的 boost，即使在重建时也会导致与 #1 相同的问题。

您可以通过检查命令行来确定这一点（make -Bsn 或 compile_commands.json，例如，取决于您的工具）。另一个技巧是包含 boost/version.hpp 并查看 BOOST_VERSION 的计算结果
最后，库是使用不同的编译器版本或编译器标志构建的，这可能会导致 synbol 不兼容（这是一个 QoI 问题，您可能需要向 Boost 开发人员报告）。

这是假设 ABI/ODR 问题，以防您想验证这种可能性。

【讨论】：

代码是从头开始构建的，make clean，甚至是从一个干净的 git 克隆。甚至写了一个干净的存根 .cpp，只有一行是 'options_description desc("foo");仍然得到错误。重建了boost库，一切都很好。发现库的进一步问题也是不匹配的。由于系统处于封闭网络上，我仍然需要确定 debian 镜像是否已过期。
系统上没有其他库版本，因此也不与旧对象重新链接。因此，上面的#3 是剩下的唯一选择，即软件包是用不同的标志构建的，因此与我的构建不兼容。如何知道用于构建库的编译器标志是什么？
你会从文档中知道。对于 deb repos，“文档”位于 deb-src 包中，您可以在本地检查/执行（debuilder、dpkg-build 和朋友）。
但通常你可以期望发行版包坚持发行版默认值。因此，发行版默认 gcc、-O2、-std=c++03 将是典型的。线程将被启用，但不一定是 ICU、MPI、python（？）。
我记得在某些平台上反复出现的一件事是，当平台 GCC 构建时与 std::string (_GLIBCXX_USE_CXX11_ABI) 的 ABI 兼容性，这在一段时间内是一个常见的链接陷阱。这并不是说这是你的问题（太老了？），而是为了给你灵感，让你了解需要注意的 env 依赖项。