使用使用较新版本的 g++ 编译的共享对象
我有一些必须使用 g++4.5 编译的共享对象，我希望它们能够链接到使用 g++4.1 和 g++4.2 编译的应用程序中。
据我了解，他们不能保证不同版本的 libstdc++ 彼此兼容，因此如果不进行一些更改，这将无法工作。
有没有一种标准方法可以在目标计算机上安装较新版本的 g++ 及其相关库？
I have some shared objects which have to be compiled with g++4.5, and I would like them to be able to be linked into applications compiled using g++4.1 and g++4.2.
It's my understanding that their is no guarantee that the different versions of libstdc++ will be compatible with each other so this won't work without some changes.
Is there a standard way to do this short of installing a newer version of g++ and it's related libraries on the target machines?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只要体系结构相同，并且您没有使用新版本独有的功能，共享对象就应该可以正常工作。
As long as the architecture is the same, and you are not using features exclusive to the newer version, the shared objects should work fine.
测试一下看看它是否有效（使用不匹配的 GCC 版本）怎么样？如果它有效，则无需为此付出任何特别的麻烦。也就是说，除非你在这里处理生命支持系统，但我猜不是。
如果 STL 容器等通过库的 API 传递，那么在实践中您更有可能遇到问题。如果库仅在内部使用 STL，它就可以“正常工作”。
How about just testing it and seeing if it works (with mismatched GCC versions)? If it works, no need to go to any particular trouble about it. That is, unless you're dealing with life-support systems here, but I'm guessing not.
You're more likely to have problems in practice if STL containers and such are passed through the libraries' APIs. If the libraries use the STL internally only, it could "just work."