Binary cross-compiler compatibility of C libraries on Windows

Question

My question is similar to this one, but also regards static libraries:

We have a cross-platform C++ header library that builds nicely under Windows/Linux/Os X that works on multiple compilers and both 32 and 64 bit. When the user has zlib or libbz2 installed, the build system enables some functionality in the library via #ifdefs.

To make it easier for our users, we want to ship libraries such as zlib and libbz2 for Windows, either in binary format or as source with few clicks to install. (On Linux and Mac Os X, the libraries can simply be installed as system packages are in fact they are available in most standard installs, as far as I can tell).

The final solution should enable users to use Visual C/C++ compilers 2005, 2008 and 2010 as well as MinGW on 32 and 64 bit Windows to easily link against zlib and libbz2. We are only concerned with C libraries at the moment and the foreseeable future.

The libraries should be built seperately, we do not want to integrate building them into our build system.

As far as I can see, there are at least two degrees of freedom here:

• Whether to use static libraries or DLLs.
• Whether to ship binary libraries or let users build their own libraries.

Another point is that users should be able to link the libraries both against debug and optimized versions of their program. I am not an expert in Windows programming, but as far as I could find out on the internet and from other developers at work, there is this (unusual?) distinction between debug and release builds on Windows. Apparently, you cannot link debug programs against release libraries and vice versa. Is this correct?

Okay, so let me maybe summarize all this again for clarity: (1) What is the best way to ship dependency C libraries for our C++ compiler? (2) If we later also want to ship C++ libraries, letting the user build from source with each compiler is the only feasible way, right?

Answer 1

What is the best way to ship dependency C libraries for our C++ compiler?

There is no perfect solution, but you will make it a lot easier for your users if ship DLLs, along with the corresponding header files and import libraries for the compilers that you think they'll be using, at least for Visual Studio. Note that most compilers provide tools to create an import library from a DLL binary.

You could also ship the libraries in source form, and provide a script that builds them on different compilers.

If we later also want to ship C++ libraries, letting the user build from source with each compiler is the only feasible way, right?

In general it is a very bad idea to use DLLs that export C++ classes and methods, since these are exported in a compiler dependent way, effectively forcing you to provide a different DLL for each supported compiler. I take the following measures when I work with C++ libraries:

1. build static libraries, never DLLs.
2. incorporate the build of the C++ library into the build of my project (as a dependent project, for example), ensuring that everything is built by the same compiler.

If I understand this right, your users are the ones that are building an application, you are just providing them with your header library. So it seems to me in this case you will need to document how they can add a C++ library to their application, and maybe the best way to do that would be to provide a fully working sample application that also builds the C++ library from source, at least targeting Visual Studio and any other compilers that you know your users may use.

Good luck.

Answer 2

For maximum binary compatibility the best way is to expose your c/c++ libaries as COM on Windows platform

COM objects can be consumed from C , C++ and .NET languages