Question

On Windows, when using g++ 4.6 (mingw) and -std=c++0x and linking with a third party static library (which was provided by the vendor for use with mingw), the application works fine. When I switched to g++ 4.7.2 (mingw) so that I could use -std=c++11, the application builds fine but crashes when run. If I comment out calls to the vendor provided library then it doesn’t crash. I asked customer support of the library vendor and was told that this was not supported.

My question is, “Are there any ABI incompatibilities” when going to a newer version of the g++ compiler? Is it not backward compatible? Aren’t newer versions of the compiler supposed to work with existing and legacy 3rd party static libraries?

Note that this only happens on Windows (mingw) platform. Works fine on Linux.

I have added more info on this:

Has anyone used Chilkat’s MinGW C++ (static) libraries in a windows application whose source is compiled with g++ 4.7.2 with -std=c++11 compile option? The app crashes when Chilkat api is accessed (for e.g CkString object is instantiated). Works fine on g++ 4.6.2 (where I use std=c++0x).
On Linux with g++ 4.7.2 this program works fine. If there is ABI incompatibility when moving from 4.6.2 to 4.7.2 then it shouldn’t work on Linux also, right? Why would static library chilkat-9.3.2/lib/libchilkat.a created by vendor for use with MINGW care if the rest of the program is compiled with the latest g++ compiler — is this a MINGW specific change in ABI?

#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
Starting program: test_chilkat.exe
[New Thread 4704.0x1a44]

Program received signal SIGSEGV, Segmentation fault.
0x00404442 in CkObject::CkObject() ()

Answer 1

MinGW 4.6.2 is definitely generating different code to call the CkString constructor than 4.7.2.

Here’s the command line I used to compile your test program to the assembly code file (where ./include is the location of the Chilkat headers):

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

Here are annotated disassemblies bookended by the two printf() calls (which GCC generates as puts() calls).

• 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
  

As you can see, 4.6.2 passes the “this” pointer to the constructor on the stack (which is what the Chilkat library expects). 4.7.2 passes the “this” pointer in ecx.

It looks like starting with 4.7.0. MinGW changed the C++ class-member calling convention to __thiscall. See http://mingw-users.1079350.n2.nabble.com/MinGW-GCC-4-7-0-released-td7578133.html

It looks like you can override that default using the -mabi=sysv option, which makes your test program work for me:

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

However, you’ll probably be buying yourself more trouble with other libraries in more complex programs – for example, you’ll almost certainly need to rebuild libstdc++.a at the very least.

I’d press the Chilkat developer for a 4.7.x library a bit more…