c++ - 链接 libboost_log.so 使 boost::asio::io_service::run 立即退出

Question

这是设置:

boost1::asio::io_service         _ios;
boost::asio::ip::tcp::acceptor  _acceptor;`
...
_acceptor(_ios)
...
boost::system::error_code ec;
int rc = _ios.run(ec);

使用 gdb 我看到运行调用跳转到 boost::asio::impl::io_service::run
这里有一点 boost

boost/asio/impl/io_service.ipp:

std::size_t io_service::run(boost::system::error_code& ec)
{
  return impl_.run(ec);
}

这里证明 impl_ 是 linux 情况下的 task_io_service。

boost/boost/asio/io_service.hpp

#if defined(BOOST_ASIO_HAS_IOCP)
namespace detail { typedef win_iocp_io_service io_service_impl; }
#else
namespace detail { typedef task_io_service io_service_impl; }
#endif

...

private:
  typedef detail::io_service_impl impl_type;
#if defined(BOOST_ASIO_HAS_IOCP)
  friend class detail::win_iocp_overlapped_ptr;
#endif

...

impl_type& impl_;

如果我在编译期间不链接 -lboost_log，那么 impl_run 调用将被解析(通过 plt stub 调用、ld_trampoline.S dl-runtime_resolve 和 dl-runtime.c _dl_fixup)到 boost::asio::detail::impl::task_io_service::run 在我的二进制文件中，run() 开始等待接受器提供的工作。

如果我通过 GDB 进行链接 boost ，我会看到此调用被解析为 libboost_log.so 符号 _ZN5boost4asio6detail15task_io_service3runERNS_6system10error_codeE 并且几乎立即退出运行。

nm -D libboost_log.so 确认符号存在，这不是我的链接问题。

为什么libboost_log.so中有这个task_io_service3run符号？这似乎是 boost 错误，不是吗？有没有办法确保预期的方法解析？

Answer 1

简而言之，Linux 上的运行时符号解析在符号可见性方面起作用。如果符号在随应用程序加载的一个或多个共享目标文件中外部可见，则运行时链接器可以自由选择任何一个实现并将其用于所有其他共享目标文件。这与编译时链接过程非常相似，它允许遵守多种语言规则(例如，获取函数的地址必须产生相同的地址，无论该地址在程序中的何处被获取)。

Boost.Log 确实使用 Boost.ASIO 来实现它的一些功能(特别是基于网络的系统日志接收器)。 Boost.ASIO 将其符号标记为外部可见，因此它们从 Boost.Log 共享对象中导出。

现在 Boost.ASIO 不使用 ABI namespace 或任何其他技术来根据库版本或配置使符号名称不同。这意味着任何使用 Boost.Log 和 Boost.ASIO 的应用程序或库必须使用相同版本的 Boost.ASIO，配置方式与构建 Boost.Log 时的配置方式相同。否则，由于 ABI 不兼容，您可能会在您或 Boost.Log 对 Boost.ASIO 的使用中观察到各种未定义的行为。我怀疑这可能是您遇到问题的原因。

检查您在构建代码和 Boost.Log 时使用的 Boost.ASIO 版本是否相同。检查所有宏在两种情况下的定义方式是否相同。检查您是否正在使用任何与 ABI 相关的编译器开关。