(A helpful note from a Chilkat customer, reproduced in slightly edited form with permission)
The primary issue was that I was creating a Windows DLL (using MinGW)
rather than a Windows executable. Now, whilst I agree this shouldn’t
make any difference it seems that it does.
On the web site (http://www.chilkatsoft.com/downloads_mingw.asp) you
indicate that MinGW systems should be linked with:
-Wl,–enable-auto-import option when linking. Also, link with
libcrypt32.a, libws2_32.a, and libdnsapi.a”
Thus we would use:
g++ -Wl,--enable-auto-import linkSample.cpp -o"linkSample.exe" libchilkat-9.1.2.a /MinGW/lib/libcrypt32.a /MinGW/lib/libws2_32.a /MinGW/lib/libdnsapi.a
Now this works perfectly if you’re using g++, however, if the project is
C based (rather than C++), the IDE (and most programmers, including
myself) will tend to use gcc rather than g++ to link.
This is what causes all the ‘new’ and ‘delete’ operators to go missing
on the link. g++ pulls in the appropriate c++ bindings but gcc (by
Building a C++ DLL:
g++ -mdll -mconsole -Wl,--enable-auto-import dllmodule.cpp -o"dllmodule.dll" libchilkat-9.1.2.a /MinGW/lib/libcrypt32.a /MinGW/lib/libws2_32.a /MinGW/lib/libdnsapi.a
Building a C DLL
g++ -mdll -mconsole -Wl,--enable-auto-import dllmodule.c -o"dllmodule.dll" libchilkat-9.1.2.a /MinGW/lib/gcc/mingw32/4.5.2/libstdc++.dll.a /MinGW/lib/libcrypt32.a /MinGW/lib/libws2_32.a /MinGW/lib/libdnsapi.a
Where the library “/MinGW/lib/gcc/mingw32/4.5.2/libstdc++.dll.a”
fixes up all the C++ requirements when linking the C module and
is crucial to a successful build.