3

I know that if I link my c++ program to a dynamic library (DLL) that was built with a different version of Visual Studio, it won't work because of the binary compatibility issue. (I have experienced this with Boost library and VS 2005 and 2008)

But my question is: is this true for all versions of MSVS? Does this apply to static libraries(LIB) as well? Is this an issue with GCC & Linux as well? and finally how about linking in VS to a DLL built with MinGW?

By the way aside from cross-platform or cross-compiler, why can't two version of the same compiler(VS) be compatibile?

p00ya00
  • 796
  • 1
  • 10
  • 20
  • possible duplicate of [Can I link object files made by one compile to those made by another one?](http://stackoverflow.com/questions/5728116/can-i-link-object-files-made-by-one-compile-to-those-made-by-another-one) – AProgrammer Apr 22 '11 at 16:28
  • 1
    To my knowledge MS has never broken backwards compatibility by changing the ABI so I think the compatibility issue is a red herring here. Though that is not to say you can end up in [`DLL hell`](http://en.wikipedia.org/wiki/DLL_hell) because of incompatible DLLs. Also you need to watch types of DLL you link against. If your application is Multi-threaded debug you need to link against the Multi-thread debug version of the appropriate DLL. – Martin York Apr 22 '11 at 17:42

3 Answers3

2

Hi. I know that if I link my c++ program to a dynamic library (DLL) that was built with a different version of Visual Studio, it won't work because of the binary compatibility issue. (I have experienced this with Boost library and VS 2005 and 2008)

I do not remember ever seeing MS changing the ABI, so technically different versions of the compiler will produce the same output (given the same flags (see below)).

Therefore I don't think this is not incompatibilities in Dev Studio but changes in Boost.
Different versions of boost are not backwards compatible (in binary, source they are backward compatible).

But my question is: is this true for all versions of MSVS?

I don't believe there is a problem. Now if you use different flags you can make the object files incompatible. This is why debug/release binaries are built into separate directories and linked against different versions of the standard run-time.

Does this apply to static libraries(LIB) as well?

You must link against the correct static library. But once the static library is in your code it is stuck there all resolved names will not be re-resolved at a later date.

Is this an issue with GCC & Linux as well?

Yes. GCC has broken backwards compatability in the ABI a couple of times (several on purpose (some by mistake)). This is not a real issue as on Linux code is usually distributed as source and you compile it on your platform and it will work.

and finally how about linking in VS to a DLL built with MinGW?

Sorry I don't know.

By the way aside from cross-platform or cross-compiler, why can't two version of the same compiler(VS) be compatibile?

Well fully optimized code objects may be compressed more thus alignment is different. Other compiler flags may affect the way code is generated that is incompatible with other binary objects (changing the way functions are called (all parameters on the stack or some parameters in registers)). Technically only objects compiled with exactly the same flags should be linked together (technically it is a bit looser than that as a lot of flags don't affect the binary compatibility).

Note some libraries are released with multiple versions of the same library that are compiled in different ways. You usually distinguish the library by the extension on the end. At my last job we used the following convention.

libASR.dll   // A Sincgle threaded Relase  version lib
libASD.dll   // A Single  threaded Debug   version
libAMR.dll   // A Multi   threaded Release version
libAMD.dll   // A Multi   threaded Debug   version
Martin York
  • 257,169
  • 86
  • 333
  • 562
  • "This is not a real issue as on Linux code is usually distributed as source" <- I don't think this is true these days. Most people install software from binary packages. – Tamás Szelei Apr 22 '11 at 18:41
  • Thank you very much! So you are saying, if for example I use prebuilt Qt libraries for VS2008 in VS2010 and it didn't work, its because those libraries were built using different flags/optimizations, and it is not a backward compatibility issue with VS or its c++ runtime library? – p00ya00 Apr 22 '11 at 18:47
  • 1
    @ Tamás Szelei: On most systems I use the package management system works with source not binary. apt-get for example downloads compiles and install. As does the perl installer etc. I am sure packages are provided in binary format but I would suggest this is the exception not the rule on Linux. – Martin York Apr 22 '11 at 18:55
  • @p00ya: Or you potentially have different versions of qt or different versions of an underlying library like boost. – Martin York Apr 22 '11 at 18:56
0

If properly built, DLLs should be programming-language and version neutral. You can link to DLLs built with VB, C, C++, etc.

You can use dependency walker to examine the exported functions in the dll.

Steve Wellens
  • 20,506
  • 2
  • 28
  • 69
0

To answer part of your question, GCC/Linux does not have this problem. At least, not as often. libstdc++ and glibc are the standard C++/C libraries on GNU systems, and the authors of those libraries go to efforts to avoid breaking compatibility. glibc is pretty much always backward compatible, but libstdc++ has broken ABI several times in the past and probably will again in the future.

It is very difficult to write stable ABIs in C++ compared to C, because the automatic features in C++ take away some of the control you need to maintain an ABI. Especially once you get into templates and inline functions, where some of the code gets embedded in your application rather than staying contained in the shared library. That means that the object's structure can't ever change without requiring a recompilation of the application.

In practice, it isn't a huge deal on Windows. It would be fantastic if Microsoft just made the MSI installer know how to grab Microsoft-provided DLLs from Windows Update when an app is installed that needs them, but simply adding the redistributable to an InnoSetup-generated installer works well enough.

Sean Middleditch
  • 2,517
  • 18
  • 31
  • I could be wrong but MS has never to my knowledge broken the ABI. GCC on the other hand has done it several times. Which is why OpenSource is distributed as source. – Martin York Apr 22 '11 at 17:39
  • @Martin - The GCC ABI has not been changed since 3.4 (2004) while MSVC breaks its ABI every major release. See [Porting Visual C++ Code to Visual Studio 2005](http://www.devx.com/cplus/10MinuteSolution/28908/1954). – linuxbuild Apr 22 '11 at 21:43
  • @user720860: I don't see any ABI changes, this article is about bringing DevStudio inline with standard C++. If you write non con-formant C++ then you should not expect your code to be portable (let alone upgradable) so not a big surprise there. GCC 3.2 (change) 3.3 (change) 3.4 (change). – Martin York Apr 25 '11 at 07:33
  • @Martin: either you don't understand the question or you don't understand my answer, and you misunderstand why Open Source software is (sometimes) distributed as source. The OP is asking why code compiled with MSVC has binary compatibility errors with code compiled with different versions of MSVC (note he mentioned linking, not compiling). I explained why, correctly. He then asked if GCC/Linux has those sorts of issues, and I answered that completely accurately. I then gave him additional background information on why these things happen, again completely accurately. – Sean Middleditch Jun 06 '11 at 05:42
  • @seanmiddleditch: Of course. I let the votes speak on who is correct :-) – Martin York Jun 06 '11 at 14:26