4

The question says it all.

I understand that VC11 is currently only in beta, but what I'm asking is:

  1. experience with trying to link with a closed source (widely used if possible) library compiled with vc10
  2. specifications from Microsoft saying explicitely if yes or no the vc11 will be able to link with vc10 libraries.

I'm talking about C++ case only.

Klaim
  • 67,274
  • 36
  • 133
  • 188
  • Is it a static or dynamic library? – jalf Apr 03 '12 at 15:05
  • I'm asking for all cases, so feel free to explain in which case it is or not possible to link such binaries together. – Klaim Apr 03 '12 at 15:07
  • @Klaim I don't have anything specific from Microsoft, but I don't see why you wouldn't be able to statically or dynamically link into a library built with VC10 on VC11. For static linking you need the include headers and the lib, for dynamic linking you need the DLL: neither of those are dependent on the visual studio version. – Kiril Apr 03 '12 at 15:10
  • @Lirik The generated decorated symbol names might be different if they've changed the C++ ABI. Ditto DLLs/EXEs built using the shared runtime by two different versions might allocate and release memory on different heaps so you'd need to be careful about exchanging ownership of objects between them (which can include implicit destruction in C++ etc.) – Rup Apr 03 '12 at 15:13
  • @Lirik Well, vc10 binaries aren't compatible with previous msvc versions, so you never know? – Klaim Apr 03 '12 at 15:13
  • @Klaim Sure, but I doubt Microsoft will break **backward-compatibility**. VC10 binaries might not be compatible with previous MSVC versions, but binaries built in previous MSVC versions should be compatible with VC10... I would assume the same goes for VC11. – Kiril Apr 03 '12 at 15:25
  • @Lirik As I said, it wasn't the case for several revisions of msvc, so I don't think you should assume that. The only thing you can assume is that it is possible that one specific library works with any other libraries because the library author made sure it is (as suggested by one of the answers). – Klaim Apr 03 '12 at 15:28
  • 2
    @Link: It has never been the case that you can link (either dynamically or statically) between C++ libraries compiled for one MSVC version and for one other version. The standard libraries are incompatible. C libraries on the other hand may work fine, if you provide both runtimes (or link statically with the msvcrtXXX.lib). – Alexandre C. Apr 03 '12 at 15:32

4 Answers4

3

You may want to read this answer for the case of dynamic linking.

Regarding static linking, I think you can't safely link C++ libraries written with VCx with code compiled with VCy. For example, STL containers implementations change from version to version (and even within the same version, there are changes between debug and release mode, and settings like _HAS_ITERATOR_DEBUGGING, etc.).

Quoting VC++ STL maintainer:

The STL never has and never will guarantee binary compatibility between different major versions. We're enforcing this with linker errors when mixing object files/static libraries compiled with different major versions that are both VC10+ [...]

Community
  • 1
  • 1
  • 2
    I understand this, but that's only part of the answer. I'm asking "in general", then if you can add specifics is better. – Klaim Apr 03 '12 at 15:17
  • @Klaim: I've added a note for the case of static linking. –  Apr 03 '12 at 16:05
1

For dynamic libraries, there should be no problem, as they follow well-defined ABIs. You can link to dll's from any compiler, any time.

Static libraries are trickier. As far as I know, Microsoft has never guaranteed cross-compiler compatibility for those. In particular, features such as link-time code generation have been known to break compatibility between earlier releases. .lib files do not have a single well-defined format like DLLs do.

It might work, because Microsoft rarely breaks compatibility unless they have to, but as far as I know, it is not guaranteed.

Of course, if the actual functions and types exposed by the DLLs don't match up, you'll run into problems.

In VC11, the sizes of almost all standard library data structures have been changed (Microsoft finally employs the empty base class optimization, effectively reducing the size of all containers which use the default allocator.), so trying to pass a std::string from a DLL compiled with VC10 into a module compiled by VC11 will certainly break.

jalf
  • 243,077
  • 51
  • 345
  • 550
  • For dynamic libraries, my understanding is that it's not true for msvc9 vs msvc10, or am I missing something? – Klaim Apr 03 '12 at 15:28
  • DLL's follow a very specific format. They have to, because it's not just a file used by the compiler, it's intended to be loaded and called by the OS. The OS must be able to load a DLL when you call `LoadLibrary`, regardless of which compiler produced it. It has to be able to look up symbols in the DLL, and so on. So there should be no problem using DLLs built with MSVC9 and 10 together. – jalf Apr 03 '12 at 15:32
  • But what about DLLs with C++ standard library usage in the interface? That would cause problems if the class structure changes, even if you could compile and link. – crashmstr Apr 03 '12 at 15:37
  • 1
    Oh sure. I was thinking just in terms of whether you could link against a dll generated by a different compiler (you can). You're right, you can't safely pass C++ objects across DLL boundaries if their structure changes. – jalf Apr 03 '12 at 15:50
1

That's a resounding no! Every major release of VS has a new version of the dynamic CRT, names are msvcr90.dll for VS2008, msvcr100.dll for VS2010, msvcr110.dll for VS11.

Using the dynamic CRT (/MD compile option) is important when you return C++ objects like std::string from an exported function, or otherwise return any pointer that needs to be deleted by the client code. That can only work properly when the client code is using the exact same version of the CRT as the DLL. Implicit is that this won't be the case when these chunks of code each have their own dependency on a msvcrXXX.dll version, they'll inevitably have incompatible CRT versions that don't share the same heap allocator.

You can write DLLs that are safe to use with any CRT version but that requires carefully crafting the API so that these dependencies do not exist. The COM Automation model is an example of that.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
0

I don't see any reason why they could be incompatible. No matter what C++ compiler you have used to produce LIB files as soon as they follow format specification. You could check this question if you are interested in details of format.

Community
  • 1
  • 1
Sergey Sirotkin
  • 1,668
  • 11
  • 7
  • 2
    Because compilers (even different versions of the same) might not generate the same name mangling. vc10 binaries cannot be linked by vc9 ones for example (assuming C++, C is fine). – Klaim Apr 03 '12 at 15:14
  • You can't usually mix C++ objects between compilers, e.g. you certainly can't mix Mingw C++ objects with MSVC C++ objects as in the question you've linked to. The exception handling mechanism is different for a start (the native Windows exception mechanism - SEH - is patented so GCC uses something else) and the mangled symbol names are generated using different schemes too. – Rup Apr 03 '12 at 15:16
  • Which format specification? Do you know of one for `.lib` files? As far as I know, no specification exists. – jalf Apr 03 '12 at 15:27
  • @jalf, in the question I mentioned there is a link to the spec: http://kishorekumar.net/pecoff_v8.1.htm – Sergey Sirotkin Apr 03 '12 at 15:33
  • Interesting, I wasn't aware of that. But as far as I can see, for .lib files it just describes a certain container structure for storing .obj file contents. Does it also describe the format of .obj files? Otherwise, it doesn't really solve the problem – jalf Apr 03 '12 at 15:36
  • @jalf The obj content withing the sections is defined by COFF format: http://en.wikipedia.org/wiki/COFF AFAIK, Microsoft uses it as well. – Sergey Sirotkin Apr 03 '12 at 16:37
  • 1
    Trivial counterexample: enable link-time code generation. Your .obj files will no longer contain machine code, and thus, will not conform to this spec. :) – jalf Apr 03 '12 at 16:42