无法解析对boost::program_options::options_description::options_description的引用
首先，我知道有几个类似的帖子，但我还是要问一下。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开箱即用版本有问题吗？
回答 1
Stack Overflow用户
发布于 2020-05-23 05:57:35
我不认为在Buster的包裹会有问题。
我最好的选择是要么
- 你正在用新的库重新链接旧的对象--它们并不匹配(你是否做了一个完整的清理，例如消除这种可能性？)
通常，构建系统不做完全的头依赖，所以构建系统可能不会注意到boost头发生了变化，需要重新构建对象。
- 如果这不能解释它，那么在include路径上可能有另一个版本的boost，即使在重建时也会导致与#1下相同的问题。
您可以通过检查命令行(make -Bsn或compile_commands.json，例如，取决于您的工具)来确定这一点。另一个技巧是包含boost/version.hpp并查看BOOST_VERSION对
- 的评估。最后，可能存在一个问题，即库是使用不同的编译器版本或编译器标志构建的，从而导致不兼容的语法(这是一个QoI问题，您可能希望向Boost开发人员报告此问题)。
这假设存在ABI/ODR问题，以防您想要验证此possibility.。
https://stackoverflow.com/questions/61940143
复制相似问题
腾讯云开发者
