C++ STL 版本控制问题 +促进

发布于 2025-01-01 17:13:24 字数 972 浏览 1 评论 0原文

我一直在构建一个 C++ 库,我想将其作为单个 .so 文件分发给我的用户,并希望该 .so 文件在很大程度上与发行版无关。因此,我一直在静态链接第 3 方库(但仍然动态链接到标准库),

现在它在 CentOS 6.2(64 位)上使用 g++ 构建得很好,但在 CentOS 5.3 上构建时遇到问题。编译过程顺利,但我收到链接器错误:

cpu_timer.cpp:(.text+0x288): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<long double>(long double)'

我已经对错误进行了一些搜索,这似乎是标准库本身的版本控制问题。我的代码,或者更确切地说是 boost::thread 的代码,正在尝试调用 CentOS 5.3 中包含的标准库中不存在的较新版本的内容。

可以理解。所以我需要:

  • 静态链接到 C++ 标准库(我对此做了一些研究,这在 64 位系统上是一个巨大的痛苦。大多数 64 位系统中包含的 libstdc++.a 不是用 -fPIC 构建的,和 -fPIC 实际上是在 64 位上进行静态链接的必要条件我必须自己构建 libstdc++.a 呃...
  • 将 boost::timer 恢复到一些更兼容的版本,所以我不需要。但这也有其自身的问题:他们在 boost 网站上的哪里记录了对标准库的依赖关系(以及哪些版本)。另外,这是一个明智的做法。选择?标准库还能给我带来什么其他令人讨厌的惊喜?

鉴于我的目标(尽可能接近发行版不可知论),您会推荐哪条路线?

I've been building a C++ library that I want to distribute as a single.so file to my users, and hopefully have that .so file be, for the most part, distro agnostic. Thus, I've been linking 3rd party libraries statically (but still dynamically linking to the standard library)

Right now it builds fine with g++ on CentOS 6.2 (64 bit), but it is having issues building on CentOS 5.3. Compilation goes through fine, but I get a linker error:

cpu_timer.cpp:(.text+0x288): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<long double>(long double)'

I've done some searching on the error and it seems to be an issue with versioning of the standard library itself. My code, or rather boost::thread's code, is trying to make a call to a newer version of something that doesn't exist in the standard library included on CentOS 5.3.

Understandable. So I need to either:

  • Link statically against the C++ standard library (I've done some research about this and it is a huge pain on 64 bit systems. The libstdc++.a included with most 64 bit systems is not built with -fPIC, and -fPIC is actually a necessity to do static linking on 64 bit systems. I would have to actually build libstdc++.a myself. Ugh...
  • Revert boost::timer to some more compatible version. I'm mostly using it for portable mutexes, so I'm not in any need of bleeding-edge boost::thread features. But this comes with its own issue: Where on the boost website do they document their dependencies to the standard library (and which versions). Do they document it at all? I can't seem to find the information. Also, is this a wise choice? What other nasty surprises could the standard library have for me?

Given my goal (as close to distro agnostic as possible), which route would you recommend?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

你怎么敢 2025-01-08 17:13:24

我建议使用足够旧的 Boost 版本,以便与您希望它兼容的所有发行版兼容。

I'd say use a version of Boost that's old enough to be compatible with all the distros you want it to be compatible with.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文