27

I am creating a open-source C++ library using Visual Studio 2005. I would like to provide prebuilt libs along with the source code. Are these libs, built with VS2005, also going to work with newer versions of Visual Studio (esp VS Express Edition 2008)? Or do I need to provide separate libs per VS version?

Charles
  • 50,943
  • 13
  • 104
  • 142
StackedCrooked
  • 34,653
  • 44
  • 154
  • 278
  • no, in my personal experience i was not able to use library generated by VC6 into 2008. – Satbir Oct 21 '09 at 12:07
  • 2
    Have you considered providing DLLs instead of static libraries? Assuming you are not doing "dangerous" operations (such as memory allocation in the client code with the corresponding deallocation in your library) the clients could simply load your library regardless of what compiler you built it with or what libraries you linked it with. – John Deters Oct 21 '09 at 12:57
  • See also: http://stackoverflow.com/questions/8439595/are-compiled-lib-files-interchangeable-for-different-versions-of-microsoft-visu – DuckMaestro Oct 07 '13 at 18:26

4 Answers4

21

Not normally, no. Libraries built with the VS tools are linked into the 'Microsoft C Runtime' (called MSVCRT followed by a version number) which provides C and C++ standard library functions, and if you attempt to run a program that requires two different versions of this runtime then errors will occur.

On top of this, different compiler versions churn out different compiled code and the code from one compiler version frequently isn't compatible with another apart from in the most trivial cases (and if they churned out the same code then there would be no point having different versions :))

workmad3
  • 25,101
  • 4
  • 35
  • 56
  • > if you attempt to run a program that requires two different versions of this runtime then errors will occur. It's works for us, one of ours externals libraries use old MSVCRT*.dll – KindDragon Oct 10 '13 at 12:20
19

If you are distributing static libraries, you may be able to distribute version-independent libraries, depending on exactly what you are doing. If you are only making calls to the OS, then you may be OK. C RTL functions, maybe. But if you use any C++ Standard Library functions, classes, or templates, then probably not.

If distributing DLLs, you will need separate libraries for each VS version. Sometimes you even need separate libraries for various service-pack levels. And as mentioned by VolkerK, users of your library will have to use compatible compiler and linker settings. And even if you do everything right, users may need to link with other libraries that are somehow incompatible with yours.

Due to these issues, instead of spending time trying to build all these libraries for your users, I'd spend the time making them as easy to build as possible, so that users can can build them on their own with minimal fuss.

Kristopher Johnson
  • 81,409
  • 55
  • 245
  • 302
  • 3
    And even project settings/compiler flags can cause binary incompatible code within the same compiler version, e.g. /Zc:wchar_t (which being on by default was a breaking change in VS2005) – VolkerK Oct 21 '09 at 12:19
  • It looks like static libraries and DLLs in your answer should be the other way around... – EvgenKo423 Mar 14 '23 at 09:23
8

Generally it's not possible to link against libraries built with different compilers, different versions of the same compiler, and even different settings of the same compiler version and get a working application. (Although it might work for specific subsets of the language and std library.) There is no standard binary interface for C++ - not even one for some common platform as there are in C.

To achieve that, you either need to wrap your library in a C API or you will have to ship a binary for every compiler, compiler version, and compiler setting you want to support.

sbi
  • 219,715
  • 46
  • 258
  • 445
  • 4
    GCC defines an standard ABI that all version of GCC use. Intel's compiler uses the same ABI so libraries compiled by intel can be used by gcc. However, MSVCRT and glibc need to be same between the library and the application as mentioned by workmad3. – deft_code Oct 21 '09 at 16:47
  • 3
    @Caspin: Yes, but even this fails if not both sides of that ABI use exactly the same version of the std lib and every other library whose types they want to pass across the boundary. That's a ticket to myriads of very hard to debug errors that might only show up under certain, very rare circumstances. BTDT. – sbi Oct 21 '09 at 17:03
2

If your library project is a static library, then, you'll have to supply a build for every Visual Studio version that you want your users to be in. In the example you gave, that equates to providing both a VS2005 and a VS2008 library.

If your library project is a dynamic library, then, you evade the problems somewhat, but, it means that users will need to make sure that they use the 'Microsoft C Runtime' that's compatible with your build environment. You can eliminate that criteria should you statically link the 'Microsoft C Runtime' into your dynamic library.

Stephen Quan
  • 21,481
  • 4
  • 88
  • 75