9

Some projects provide a single set of "Windows" binaries for C (and possible C++ - not sure) libraries. For example, see the links on the right side of this libxml-related page.

I'm pretty sure there's no way to convert between VC++ .lib files and MinGW GCC .a files, so calling them "Windows" rather than "Microsoft" binaries seems a tad misleading. But I'm also surprised that there's no apparent need for different binaries for different VC++ versions.

I seem to remember, many years ago, having problems writing plugins for tracker-style music program (Jeskola Buzz) because that program was using VC++6, and I had upgraded to VC++7. I don't remember the exact issue - it may have been partly DLL related, but I know those don't need to care about VC++ version. I think the issue related to the .lib files provided and maybe also to the runtime libraries that they linked to. It was a long while ago, though, so it's all a bit vague.

Anyway, can libraries compiled by one version of MS VC++ be linked into projects built with another version? What limitations apply, if any?

I'm interested in both C and C++ libraries, which will be called from C++ projects (I rarely use C, except for C libraries called from C++).

  • 2
    The binary format of .lib and .obj files has been cast in stone for a very long time. The typical problem is the *content* of the .lib. Having a dependency on the CRT version is often a problem, can't mix the static and dynamic CRT versions for example. Or the C++ template classes, lots of flux there. – Hans Passant Dec 09 '11 at 01:23
  • @Hans - so if the .lib uses a static CRT, and is pure C, the odds are pretty good? (other than the usual free-from-where-you-malloc style issues that happen with DLLs too) –  Dec 09 '11 at 01:27
  • 2
    If the program is compiled with /MT and its just plain C then odds are good. Although those odds tend to be surprisingly low for SO users that ask a question about it. We don't hear from the rest. – Hans Passant Dec 09 '11 at 01:33
  • 1
    To add to what @Hans stated: we had a third party static library compiled in VS8, that we kept on using once we had moved to VC9 and 10 without any issues. I guess we were just lucky though.... – Ralf Dec 09 '11 at 05:25
  • 1
    See also: http://stackoverflow.com/questions/1600399/are-c-libs-created-with-different-versions-of-visual-studio-compatible-with-ea – DuckMaestro Oct 07 '13 at 18:27
  • "I'm pretty sure there's no way to convert between VC++ .lib files and MinGW GCC .a files" you are wrong. There are converters `.lib to .a and vice versa`, since the difference is just the way `.obj` files are archived. Unpack a `.lib` and repack it into a `.a` - ta-da, you just converted VC++ library file to MinGW GCC library file. – Kotauskas Aug 14 '18 at 09:52
  • @ValdislavToncharov - no, it's not just the archive format, the object format itself differs. And even when you convert those, the issue is different ABIs - Application Binary Interfaces (e.g. calling conventions). Relatively recently, Visual C++ ABIs are now supported by Clang (not sure if 100%), which uses the same object and archive file formats as GCC, so I'm not so surprised that relatively recently there may be a use case for converters and they may now exist - but this question predates that. –  Aug 14 '18 at 21:58
  • @VladislavToncharov - [This question](https://stackoverflow.com/questions/6329688/llvm-and-visual-studio-obj-binary-incompatibility), also from 2011, has an answer pointing out that VC++ calling conventions were already supported (needed for DLLs) but also makes clear that the C++ ABIs were not supported by LLVM (the back end underlying Clang) - only the relatively simple C ABIs. It's still possible there were converters in 2011 and I just didn't find them at the time because they were relatively obscure, but even if they existed, they wouldn't (and still won't) convert C++ ABIs. –  Aug 14 '18 at 22:12
  • @VladislavToncharov - [Clang 8 Documentation](https://clang.llvm.org/docs/MSVCCompatibility.html) claims "Clang’s support for MSVC’s C++ ABI is a work in progress". TBH I thought the current Clang was version 6, so seeing documentation for version 8 is itself slightly surprising, and I'm guessing means the "work in progress" state is going to persist for at least one stable version after the current one. –  Aug 14 '18 at 22:18
  • @VladislavToncharov - actually, I'm still not finding any converters, so if you know one it would be handy if you could provide a link to it. What I do see is relatively little need - based on what I've just found, MSVC++ has been able to use .a files for quite a while, and of course MinGW GCC is able to use .lib files. In both directions, though, that's assuming ABI compatibility, which (until recently) was only likely for C, not C++. –  Aug 14 '18 at 22:30

1 Answers1

4

The MS COFF format (.lib, .obj, etc) is the same for all VC++ versions and even for other languages.

The problem is that .obj files depend on other .obj (.lib) files.
For C++ code, there is a happy chance that code won't compile with new version of VC++ standard library implementation. For example, an old version of CRT used extern "C++" void internal_foo(int), and newer CRT uses extern "C++" void internal_foo(int, int), so linker will fail with "unresolved external symbol" error. For C code, there is a chance that code will compile, because for extern "C", symbol names doesn't encode whole signature. But at runtime application will crash after this function will be called.
The same thing can happen if layout of some data structure will change, linker will not detect it.

Abyx
  • 12,345
  • 5
  • 44
  • 76