混合编译器

发布于 2024-11-18 13:44:36 字数 388 浏览 2 评论 0原文

我想知道是否可以将使用 gcc4.2 编译的 c++ 程序与在 gcc4.5 等更高版本中编译的共享 c++ 库链接起来。

我尝试过这样做,但是遇到了一些不同类型的问题。 编译共享库 gcc5.3 时,我收到一条消息:

*“malloc:对象 0x7fff707d2500 的错误:正在释放的指针未分配 在 malloc_error_break 中设置一个断点来调试“*。

如果我尝试使用 gcc4.6 编译共享库,我会得到非常奇怪的行为。std::stringstream 类无法正常工作。写入流后生成的字符串为空。

是否可以做到这一点?或者我正在尝试一些不可能的事情?我希望这是可能的,因为我正在动态链接我在 MacOSX 上运行的库

I am wondering if it is possible to link a c++ program compiled with gcc4.2 with a shared c++ library that is compiled in a later version like gcc4.5.

I've tried to do this, but have run into some different kind of problems.
When compiling the shared library gcc5.3 I get a message saying:

*"malloc: error for object 0x7fff707d2500: pointer being freed was not allocated
set a breakpoint in malloc_error_break to debug"*.

If I try to compile the shared library with gcc4.6 I get really strange behaviour. The std::stringstream class is not working correctly. The resulting string is empty after writing to the stream.

Is it possible to do this? Or am I trying something that is impossible? I was hoping that this was possible since I'm linking the lib dynamically. Btw I'm running on MacOSX.

BR

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

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

发布评论

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

评论(2

暗恋未遂 2024-11-25 13:44:36

从gcc 3.0开始,g++遵循Itanium ABI,所以理论上应该没有问题。但是,g++ 4.2 具有 CXXABI_1.3.1,而 g++ 4.5 具有 CXXABI_1.3.4(请参阅此处< /a>)。所以我会小心。如果没有差异,就不会增加修订号。

此外,glibc++ 在这些版本之间经历了 5 次修订,这可能是您看到 std::stringstream 做有趣事情的原因之一。

最后,存在许多配置选项(例如使字符串完全动态或不完全动态),它们直接影响标准库的行为和兼容性。给定两个(随机的、未知的)构建,您甚至无法知道它们具有相同的配置选项。

Beginning with gcc 3.0, g++ follows the Itanium ABI, so in theory there should be no problem. However, g++ 4.2 has CXXABI_1.3.1 whereas g++ 4.5 has CXXABI_1.3.4 (see here). Therefore I'd be careful. One does not bump up revision numbers if there are no differences.

Further, the glibc++ has gone through 5 revisions between those versions, which may be one reason why you see std::stringstream do funny things.

Lastly, there exist many config options (such as for example making strings fully dynamic or not) which affect the behaviour and compatibility of the standard library directly. Given two (random, unknown) builds, you cannot even know that they have the same config options.

晨敛清荷 2024-11-25 13:44:36

根据我的经验,ABI 兼容性意味着 C++ 库可以毫无问题地相互链接。

然而,由于 C++ 使用了如此多的内联函数,这并没有多大意义。

如果标准 C++ 库使用了所有内联函数或使用了所有库函数,那么您可以将旧版本 GCC 编译的代码与新版本一起使用。

但事实并非如此。该库混合了内联和外部库代码。这意味着,如果 std::string、std::vector 或语言环境或其他内容发生更改,则旧 GCC 中的内联代码与新 GCC 链接的库代码不同步。

In my experience the ABI compatibility means that C++ libraries can link to each-other without problems.

However, because C++ uses so many inline functions this doesn't mean much.

If the Standard C++ Library used all inline functions or used all library functions then you could use code compiled with older versions of GCC with newer versions.

But it doesn't. The library mixes inline and external library code. This means that if something is changed in std::string, or std::vector or locales or whatever, then the inlined code from the old GCC is out of sync with the library code linked from the new GCC.

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