3 ms·

Microsoft C++ supports static linking with the standard library, which you should be using for release builds. That way, your program will always be using the e

Microsoft C++ supports static linking with the standard library, which you should be using for release builds. That way, your program will always be using the exact version of the standard library that it was tested with, and it's guaranteed not to interfere with anything else on the target system.

jevinskie 13y ago
What can you do for the situation where you ship a library instead of an executable? My team's product is moving to statically link libstdc++ and libgcc thanks to the runtime linking exception in GCC. It will allow us to use C++11 on old systems. We are grateful that libstdc++ is backwards compatible to GCC 3.4 (other libstdc++'s can link against us)! I'm looking into statically linking musl libc so our product could (in theory) run on any 2.6/3.0 kernel. =)
- vetinari 13y ago
  glibc itself is not supposed to be linked statically, because it itself dlopens other shared libraries - for pam, for nsswitch, etc. These are system specific (as configured by admin), so there is no one size fits all. You may statically link another libc, but then the users may wonder why your app does not works as it should, when they configure nsswitch for example and your app will not respect that.
stinos 13y ago
on the other hand there's the issue as stated in one of the other comments: If an application breaks because the internals of a library were changed, that's none other than the applications' fault. All the occasions we had an application only crash on client's machine where alway due to bugs in our code, not in the platform. (not saying that it can't happen, but it seems rare for the type of app we do) So I'd rather expose bugs by 'surrendering' to the target machine completely, than to simply never find them.
- rwallace 13y ago
  As Raymond Chen explains at length in a few of his posts, this does not matter. Sure, there's a sense in which the bug is your fault for not being infallible, but what of that? We already knew we aren't infallible. The point is, that kind of live fire debugging punishes your users, not you. And as long as you keep doing it that way, it's going to end up hitting your users in a situation where you aren't around to fix the bug. I did say you should use static linking in the release build. If you want to keep virtual machines with every version of Windows and/or the run-time library you can lay hands on in order to test debug builds of your program against them so you can find the bugs instead of letting users trip over them, there's certainly nothing wrong with that.
dblohm7 13y ago
OTOH by linking statically you cannot distribute CRT bug fixes without building new binaries. Ideally the CRT DLLs are installed with Windows Installer and can then be updated via Windows Update.

jevinskie 13y ago

What can you do for the situation where you ship a library instead of an executable? My team's product is moving to statically link libstdc++ and libgcc thanks to the runtime linking exception in GCC. It will allow us to use C++11 on old systems. We are grateful that libstdc++ is backwards compatible to GCC 3.4 (other libstdc++'s can link against us)! I'm looking into statically linking musl libc so our product could (in theory) run on any 2.6/3.0 kernel. =)

vetinari 13y ago
glibc itself is not supposed to be linked statically, because it itself dlopens other shared libraries - for pam, for nsswitch, etc. These are system specific (as configured by admin), so there is no one size fits all. You may statically link another libc, but then the users may wonder why your app does not works as it should, when they configure nsswitch for example and your app will not respect that.

stinos 13y ago

on the other hand there's the issue as stated in one of the other comments: If an application breaks because the internals of a library were changed, that's none other than the applications' fault. All the occasions we had an application only crash on client's machine where alway due to bugs in our code, not in the platform. (not saying that it can't happen, but it seems rare for the type of app we do) So I'd rather expose bugs by 'surrendering' to the target machine completely, than to simply never find them.

rwallace 13y ago
As Raymond Chen explains at length in a few of his posts, this does not matter. Sure, there's a sense in which the bug is your fault for not being infallible, but what of that? We already knew we aren't infallible. The point is, that kind of live fire debugging punishes your users, not you. And as long as you keep doing it that way, it's going to end up hitting your users in a situation where you aren't around to fix the bug. I did say you should use static linking in the release build. If you want to keep virtual machines with every version of Windows and/or the run-time library you can lay hands on in order to test debug builds of your program against them so you can find the bugs instead of letting users trip over them, there's certainly nothing wrong with that.

dblohm7 13y ago

OTOH by linking statically you cannot distribute CRT bug fixes without building new binaries. Ideally the CRT DLLs are installed with Windows Installer and can then be updated via Windows Update.