Static linking advantages

Question

I recently read a question on here about static and dynamic linking, which reminded me of some questions I've had about it. From that post, I can see what the technical difference is (including object file contents directly instead of merely pointing to it), but I'd like to know a bit more about the pros/cons of doing so.

A while ago, a friend of mine who's been programming several years was lamenting that C# isn't statically linked and saying that that was the feature he desired most for a future version. Unfortunately I'm a novice and don't really understand this statement.

Thanks for any enlightenment!

Answer 1

A statically executable contains all the objects that it needs so no external DLL will be called when executed. The advantaje is that is is portable accross a lot of platforms no matter what version of DLLs have been installed on that system. The BIG disadvantage is that you are probable wasting disk space since you are including in your executable code that is already present in system/external DLLs. Moreover I think, but I'm not very sure, that DLLs are loaded in main memory only once, no matter how many executables are using them, but if you link statically the library objects inside your executable you load the same code twice (one for the DLL used by the rest of the programs and one for your executable). On the other hand this could be an advantage instead a disatvadvantage, since the executable contains only the objects of the external libraries that it needs, not the whole library. A DLL is loaded in memory as a whole when an application needs it.

Static linking is ideal to compile small apps that you want to carry from one system to another as a small tool. I.e. it was really useful for me to have a statically compiled version of tcpdump when it was not included in every Linux distro. It was bound to work on every Linux no matter what version of Kernel, glibc or other system libraries had. Perhaps it has not so much sense in Windows world since the platforms are much more homogeneus. If you compile for Windows XP / NET vX.X it will work across a lot of computers. If you compile something for Debian X.X it will surely not work on older/newer Debians or other distros such as Redhat.

This thread can also solve your questions.

Answer 2

The advantage of static linking is that it removes external dependency on libraries - i.e. the behaviour of the library you're using is never going to change because someone changed the libraryon the disk. That's also one of the disadvantages of static linking; if the OS changes and a new version of the library is needed to work with it properly, you have to provide an upgraded version of your binary. Similarly if a bugfix is added to the library, you don't automatically get that bug fix if you've statically linked.

Most (in fact, probably all these days) operating systems can load one copy of a dynamic library for multiple processes, which is why on UNIX they're called shared objects.

Answer 3

I am not sure if static linking is a really good idea in C# to be honest, for a million reasons. One reason is that, as opposed to languages like C or C++, C# has the concept of assemblies, which are basically executable files or DLLs.

Now if you want link things statically in .NET, you either

• Merge classes from multiple assemblies into a single assembly. That would break a lot of things, like the "internal" access modifier.
• Have more than one assembly in the same executable. That would render the whole concept of assemblies useless though, and would require to redesign the approach to reflection in the .NET Framework.

I'm sure there is a clever way to avoid these problems, but I don't quite see the point of statically linking in a managed environment like .NET or Java. I mean, statically linking indeed improves performance, but not THAT much. And we don't use managed languages for their execution speed anyway.

Another issue is DLL hell, but in .NET, that's pretty much a solved issue anyway.