4

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?

Community
  • 1
  • 1
Manuel
  • 6,461
  • 7
  • 40
  • 54

2 Answers2

2

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.

Miguel Grinberg
  • 65,299
  • 14
  • 133
  • 152
  • As for the debug/release thing, the common answer is to ship _two_ copies of your dll, "Manuel.dll" and "ManuelDebug.dll", so they can link against the correct one. – Mooing Duck Oct 29 '11 at 18:11
  • Forgot to address debug vs. release in my answer. I think for general use libs like zlib you are fine shipping only release built DLLs. The problem with debug builds is that they are a MS thing, they depend on a debug version of the C/C++ standard libs, so they aren't compiler independent. – Miguel Grinberg Oct 29 '11 at 18:31
1

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

parapura rajkumar
  • 24,045
  • 1
  • 55
  • 85
  • Maximum compatibility between compilers and languages, but not necessarily with existing code. Turning normal libraries into COM components also introduces an **incredible** amount of boilerplate/overhead (I had a project go from 18k to 25kloc) in addition to placing significant restrictions on the interfaces. It does, however, make it compiler independent. – ssube Oct 29 '11 at 17:33
  • 4
    You can take the GdiPlus approach and make your C++ objects wrappers around a compiler-independent flat API. – Raymond Chen Oct 29 '11 at 17:46
  • Those restrictions are the same reason reason why it remains binary compatible. – parapura rajkumar Oct 29 '11 at 18:35