Regarding the following VC++ link problem:

“fatal error C1047: The object or library file 'c:\Chilkat\libs\x64\ChilkatRel_x64.lib'
was created with an older compiler than other objects; rebuild old objects and libraries”

This can be resolved by building without the /LTCG flag turned on. Unfortunately, it is not possible to use the /LTCG flag if you are using the Chilkat libraries. Compiling and linking your C++ application without using the /LTCG flag should resolve the problem.

In VC++ 7.0, 8.0, 9.0, and 10.0, make sure the C++ Language option ‘Treat WChar_t as Built In Type’ is set to Yes. Otherwise, you may get this link error:

error LNK2019: unresolved external symbol "public: void __cdecl CkString::appendU(unsigned short const *)

Question:

I am developing a single EXE in C++ that doesn’t make use of any external libraries and including MFC. Can I add your zip libaries to my application and still maintain the application as a single EXE?

Answer:

Yes, the Chilkat C++ libs may be linked directly into your application.  This results in a single EXE containing the Chilkat library code required to satisfy all direct and indirect references.  (The linker includes only the code needed to resolve all references.)  You may run your EXE on any computer because the licensing is royalty-free.  Internally, Chilkat does not use or reference MFC.   (Note: MFC applications may still use the Chilkat libs.  The point is this: if your application does not use MFC, then linking with Chilkat will not cause MFC to be “pulled-into” your EXE.)

When linking with a Chilkat C++ library, you must choose the .lib that matches your project’s “code generation” property setting. (With VC++ 6.0, you need to choose the pair of .lib’s that match.)

For example, in VC++ 8.0, these are the Chilkat .lib’s:

ChilkatDbg.lib
ChilkatDbgDll.lib
ChilkatRel.lib
ChilkatRelDll2.lib
ChilkatRelDll.lib

If “Dll” is in the library name, it means that you are *not* statically linking with the C runtime libs. Just because your project produces a .dll does not mean you’ll use the .lib with “DLL” in the name. The choice depends on the “code generation” project setting for each build.

I hope you can figure out the difference between “Dbg” and “Rel” without me explicitly stating it…

A Chilkat .lib with a “2″ in the name indicates that it lacks the self-extracting EXE generation features in the Zip library. Chilkat adds this extra choice because the self-extracting EXE feature (in some cases) can cause too much unused baggage to be added to the .exe.

Here are screenshots of the VC++ 6.0, VC++ 7.0, and VC++ 8.0 code generation property pages:

VC++ 8.0

VC++ 7.0

VC++ 6.0