不同的GCC方言可以链接在一起吗？ [英] Can different GCC dialects be linked together?
问题描述
我知道原则上这可能是未定义的行为，但是为了处理一个大项目，这里是我关于GCC的问题：
假设我编译一个转换单元与 gcc -std = c ++ 98 ，另一个与 -std = c ++ 11 完全相同的编译安装。是否有任何保证，我可以链接这两个目标文件，并获得一个明确定义的程序？
据我所知，潜在的问题只能来从不同的视图头文件，由于不同的宏，那些反过来最多可以添加新成员函数，但从不是成员对象，标准库类。
更新：我应该添加一个正交问题：使用两个不同的版本的GCC（例如4.3和4.6），但是同一方言选项（ -std = c ++ 98 ）？ 此GCC文档中的列表似乎表明该库在4.2之间的双向兼容。 2和4.6。
先验，不。最安全的解决方案是假设所有编译器选项都是相同的，除非编译器明确说明该选项不会影响二进制兼容性。 （在大多数编译器中非常缺乏的文档。）在实践中，在缺乏文档的情况下，控制警告的选项（ -W ... g ++）不会影响二进制兼容性，并且影响代码生成（语言级别等）的选项可能：g ++通常在不同的优化级别保持兼容性，而VC ++不支持。
另一个真正的问题是在命令行中定义预处理符号。同样，最安全的是，所有的定义都是相同的，但是也有一些常识是有道理的：人们几乎不能期望标准库已经用您的项目中使用的预处理符号来编译（例如 MYPROG_CONFIG_FILE_LOCATION ，说）。另一方面，请注意 _GLIBCXX_DEBUG 和 _GLIBCXX_DEBUG_PEDANTIC 的预处理程序定义将影响二进制兼容性（尽管g ++可确保将会得到一个图书馆版本，如果你使用它们一致）。
对于你的问题：我不会指望二进制兼容性由于标准版本，但是如果选择会影响一些预定义的预处理器符号，会破坏库中的二进制兼容性，那么就不会感到惊讶，就像你编译了一些模块一样 _GLIBCXX_DEBUG ，有些没有。它可能工作，但我不会指望它。
I know that in principle this is probably undefined behaviour, but in the interest of dealing with a large project, here's my question about GCC:
Suppose I compile one transation unit with gcc -std=c++98, and another with -std=c++11, using the exact same compiler installation. Is there any sort of guarantee that I can link the two object files and obtain a well-defined program?
As far as I can tell, the potential problems can only come from different views of the library headers due to differing macros, and those in turn would at best add new member functions, but never member objects, to the standard library classes.
Would this somehow make it acceptable to compile different parts of a larger project with different language dialect options?
Update: I should add an orthogonal question: What about using two different versions of GCC (say 4.3 and 4.6), but wht the same dialect option (-std=c++98)? The listing in this GCC documentation seems to suggest that the library is compatible in both directions between 4.2.2 and 4.6.
A priori, no. The safest solution is to assume that all of the compiler options are identical, except when the compiler specifically documents that the option doesn't affect binary compatibility. (Documentation which is sorely lacking in most compilers.) In practice, in the lack of documentation, it seems a safe bet that options which control warnings (-W... in g++) won't affect binary compatibility, and that options which affect code generation (language level, etc.) might: g++ generally maintains compatibility across different levels of optimization, where as VC++ doesn't.
Another real problem is defining preprocessor symbols in the command line. Again, the safest bet is that all of the defines be identical, but also again, some common sense is in order: one can hardly expect the standard library to have been compiled with preprocessor symbols which are used in your project (things like MYPROG_CONFIG_FILE_LOCATION, say). On the other hand, be aware that preprocessor definitions of _GLIBCXX_DEBUG and _GLIBCXX_DEBUG_PEDANTIC will affect binary compatibility (although g++ ensures that you will get a library version which works with them if you use them consistently).
With regards to your question: I would not expect to much impact on binary compatibility due to standard version, but it would hardly surprise me if the choice affects some pre-defined preprocessor symbols, in a way that would break binary compatibility in the library, much as if you'd compiled some of the modules with _GLIBCXX_DEBUG, and some without. It might work, but I wouldn't count on it.
这篇关于不同的GCC方言可以链接在一起吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
