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() ()
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...