升级到g ++ 4.7(支持c ++ 11):任何ABI不兼容?

Windows上,当使用g ++ 4.6(mingw)和-std = c ++ 0x并且与第三方静态库(由供应商提供用于mingw)连接时,应用程序工作正常。 当我切换到g ++ 4.7.2(mingw),以便我可以使用-std = c ++ 11时,应用程序生成良好,但运行时崩溃。 如果我打电话给供应商提供的库,那么它不会崩溃。 我问图书馆供应商的客户支持,被告知这不被支持。

我的问题是,“有没有任何ABI不兼容”,当去一个新版本的g ++编译器? 它不是向后兼容吗? 编译器的新版本是否应该与现有的和传统的第三方静态库一起工作?

请注意,这只发生在Windows(mingw)平台上。 在Linux上运行良好。

我已经添加了更多的信息:

有没有人在Windows应用程序中使用Chilkat的MinGW C ++(静态)库,其源代码是用g ++ 4.7.2和-std = c ++ 11编译选项编译的? 应用程序崩溃时,奇尔卡特API被访问(例如CkString对象被实例化)。 适用于g ++ 4.6.2(我使用std = c ++ 0x)。 在Linux上用g ++ 4.7.2这个程序工作正常。 如果从4.6.2移到4.7.2有ABI不兼容,那么它也不能在Linux上工作,对吗? 为什么供应商为了使用MINGW而创build的静态库chilkat-9.3.2 / lib / libchilkat.a会关心程序的其余部分是否使用最新的g ++编译器编译—这是ABI中MINGW特有的变化吗?

 #include <windows.h>
 #include <stdio.h>
 #include <CkString.h>
 int main(int argc,char * argv []){
   printf(“test chilkat \ n”);
   CkString str1;
   printf(“test done \ n”);
 }
 gdb -i = mi test_chilkat.exe
启动程序:test_chilkat.exe
 [新主题4704.0x1a44]

程序收到信号SIGSEGV,分段故障。
 CkObject :: CkObject()()中的0x00404442

Solutions Collecting From Web of "升级到g ++ 4.7(支持c ++ 11):任何ABI不兼容?"

MinGW 4.6.2肯定会生成不同的代码来调用CkString构造函数而不是4.7.2。

下面是我用来编译测试程序到汇编代码文件的命令行(其中./include./include头文件的位置):

 g++ -I ./include -S -masm=intel -std=gnu++0x test.cpp 

这里是由两个printf()调用(GCC生成为puts()调用)预先注释的反汇编。

  • 4.6.2:

     call _puts lea eax, [esp+28] ; eax gets pointer to `str1` being constructed mov DWORD PTR [esp], eax ; put the `str1` pointer on the stack call __ZN8CkStringC1Ev ; call `CkString::CkString()` ctor mov DWORD PTR [esp], OFFSET FLAT:LC1 call _puts 
  • 4.7.2:

     call _puts lea eax, [esp+28] ; eax gets pointer to `str1` being constructed mov ecx, eax ; ecx gets `str1` "this" pointer LEHB0: call __ZN8CkStringC1Ev ; call `CkString::CkString()` ctor mov DWORD PTR [esp], OFFSET FLAT:LC1 call _puts 

如你所见,4.6.2将“this”指针传递给堆栈上的构造函数(这就是Chilkat库所期望的)。 4.7.2在ecx传递“this”指针。

它看起来像从4.7.0开始。 MinGW将C ++类成员调用约定更改为__thiscall 。 见http://mingw-users.1079350.n2.nabble.com/MinGW-GCC-4-7-0-released-td7578133.html

看起来你可以使用-mabi=sysv选项来覆盖这个默认值,这使得你的测试程序能够为我工作:

 C:\temp>g++ --version g++ (GCC) 4.7.2 ... C:\temp>g++ -mabi=sysv -I ./include -g -Wl,--enable-auto-import test.cpp -o test.exe libchilkat-9.3.2.a C:\temp>test test chilkat test done 

但是,在更复杂的程序中,您可能会为其他库更麻烦,例如,您几乎肯定需要重建libstdc++.a

我会把奇尔卡特的开发人员按下一个4.7.x的库…

我是供应商(奇尔卡特),Babu的答案并不是“不支持”,而是“尚未支持”。

在每个奇尔卡特版本之间,都有不可避免的需要支持的新系统。 这些都需要时间(在奇尔卡特)来生产建筑和配送的自动化系统。 要处于新鲜事物的最前沿,期望它能立即得到奇尔卡特的支持,这是有些不合理的。

目前,奇尔卡特正在计划支持以下新系统:Windows Phone 8,Embarcadero XE3,Mono(适用于Windows,Linux,MAC OS X,iOS,Android等的跨平台),任何新版本的Perl, Python,PHP等,比如Python 3.3.0,Android for MIPS和x86。 奇尔卡特也提供API的其他方式,不一定是“新”,如提供一个类似于“C”API的DLL / .so / .dylib功能库。

作为跨平台的API合理性的一部分,重要的内部发展正在进行。 例如,“Ck *”C ++头文件和实现将被完全生成。 .NET程序集管理的头文件和实现也是如此,每个头文件和实现都调用相同的内部实现。 这将做两件事情(1)消除平台之间的任何不一致,(2)允许对外层进行改进/改变。 例如,如果需要为每个C ++类方法添加调用约定修饰符。 也许增加“_ stdcall”或“ _chilkat_call”,其中“__chilkat_call”可以在一个地方定义为“_ stdcall”或“ _thiscall”将有所帮助。 当生成Ck *头文件和方法时,这将是可能的。

总之,您的需求将在未来几个月得到支持,而不是在这个时刻。 我很抱歉,但我希望你明白。