3

I've been having a lot of conceptual issues with Microsoft's CRT. For any project you have to compile all required libraries to link against the same version of the CRT.

The first problem is when your project statically links against the CRT (/MT). Then all the dependant libraries must also link their own CRT statically. So each library has its own version of - for example - malloc(). If you compiled one of the libraries last year on system A, that CRT version may be different than the one you're currently using on another system B with service pack 3+. So if you're freeing objects allocated by the library you may run into problems.

So it seems dynamically linked CRT is the way to go (/MD). With dlls all the libraries would get the current implementation of the CRT on the system. Except that with Microsoft's Side by Side mechanism that's not what happens. Instead you get the CRT version that's stamped on the library you compiled and that version of the DLL is supplied to that library. So exactly the same problem I described before can occur. You compile a library on system A a year ago against one CRT. A year later there's a new version with upgrade. Your main program gets the DLL with one version of the CRT, the library gets the DLL with another version of CRT, same problem can occur.

So what do you do? I realize cross library memory allocation is frowned upon. But you can ignore the malloc example and come up with another one. Do you have every developer recompile every dependant library on their machine to make sure everything does use the same CRT? Then for the release you recompile every library again?

How does this work on Linux? That's my main interest. Is there a CRT supplied with GCC or the Linux system itself comes with CRT libraries? I've never seen the CRT linked explicitly in Makefils.

On Linux, what CRT do dynamic libraries link against? The most current one on the machine, or is it more "side by side" mechanism.

pnuts
  • 58,317
  • 11
  • 87
  • 139
Budric
  • 3,599
  • 8
  • 35
  • 38
  • As far as I know, it is usually not a problem to rebuild all the project and dependencies in Linux because code often available. – Lol4t0 Apr 12 '12 at 18:00
  • glibc (the GNU implementation of the C library, which covers ISO C + POSIX + some extensions) uses versioned symbols to handle compatibility between versions. Pretty much every other library author doesn't care that much about this sort of compatibility between versions, since anyway, most Linux software is distributed as source and can be recompiled at will (either by distributions, or even by the final user). – ninjalj Apr 12 '12 at 20:06
  • Well technically the issue of different code parts calling different samefunc@@version can also occur on Linux due to said symbol versions. However, unlike msvcrt, glibc still has only one malloc symbol to date (malloc@@GLIBC_2.2.5). I also don't see why it would need more than that, after all, malloc's ABI has not changed since ANSI C, and is unlikely to do so anytime soon. – jørgensen Apr 12 '12 at 20:31

1 Answers1

2

On the Linux side I think there are two basic parts of the standard library that are at issue: We have the C-runtime part, which should pretty much be ABI compatible forever. Effectively whichever version links at final link time should be fine, and you can redistribute any needed shared library with your binary if it's an older version needed for compatibility. Usually the libraries just sit side-by-side on *NIX systems.

Secondly, you have the C++ libraries. These are pretty much guaranteed to not be ABI compatible in any way, so you must rebuild every single component of a final binary against the same version of the C++ library. There's just no way around it unfortunately because otherwise you could wind up with a variety of mismatches. This is why many open source libraries don't even bother with premade library binaries: Everyone needs to build their own copy to make sure that it will properly link into their final application code.

Mark B
  • 95,107
  • 10
  • 109
  • 188
  • I think over-simplifying the Linux situation. Don't programs link against a specific major-minor libc version there too (patch version is left out to support non-ABI-changing updates)? The thing is that a lot more software is built from source on Linux platforms. Also, proper library downloads are handled by package managers. – André Caron Apr 12 '12 at 19:32
  • Are CRT and C++ STD libraries always dynamically linked? If "crt.so" is linked, will the one in the path just get used or is there a mechanism like in Windows where Windows DLL Loader looks at manifest for CRT version and fetches DLL from Windows\WinSxS? – Budric Apr 12 '12 at 19:33
  • The libraries are not always dynamically linked although in *NIX it's pretty popular to do so. It links something like `libc.so.1` where it has a version tacked on so it knows which `.so` to load at runtime (although compatible patches are allowed). – Mark B Apr 12 '12 at 19:41
  • @AndréCaron: actually, programs can link even against specific symbol versions, a good example is when linking against glibc, which has lots of versioned symbols. – ninjalj Apr 12 '12 at 20:09