Static vs. shared libraries for a media player

Question

I'm not going to go into detail on the "media player" part except the fact that it will obviously use plug-ins, which will be a simple dynamic library that is loaded at runtime. Now, I could link those plug-ins dynamically to their dependencies, or I could link them statically. Both have their advantages and disadvantage - I'm not counting Linux here, as that will use shared libraries.

The single advantage I see with using shared libraries is that the library can be updated independently of the program. On Windows, this is rarely an advantage, as the library will be next to the application using it (thanks to no official C++ ABI). On Windows, to help with reducing DLL hell and share the C libaries, I would have to use SxS, which isn't a really nice citizen.

As for static libraries, I see one big advantage: link-time optimizations. Those ave been supported by ICC and VC++ for quite a while now and GCC has a branch for them. Since I will probably be using VC++ on Windows there would be a noticeable performance improvement as the compiler (well, the actual "compiler" just converts C++ to an intermediate language, so the compiler here is the "linker") has perfect knowledge of the code and can optimize lots of stuff this way. This is the option I'm leaning towards.

My question is, which one would be the best in my specific case?

There is no concern of other applications using them as I don't count Linux in this issue (though I have no knowledge of OS X) or multiple instances (who runs the same media player twice anyway?), binary compatibility (as I'll distribute everything with the application) or easy of updating (on Windows I'll use a very efficient binary diff patcher for distributing updates).

Answer 1

I'm not completely sure of what your "specific" case is.

If your "media player" is intended for a well know unique client (or small set of clients) who will update all the media player at once or any given plugin at once under your complete supervision then I'll go for static libraries.

If that's not the case I'll go for dynamic libraries. Optimizations are good but are not as good as customer/user satisfaction. There's nothing worse than updating your xxx library to the latest version and that all the sudden things just stop to work. If you haven't control over when and how updates are made be as flexible as you can.

Response to the comment:

Usually dynamic libraries are backwards compatible for minor release versions while static linking might be dependent on a concrete version and break if you try to link it to another release. With Dynamic Linking your program might even work as long as the calls you use doesn't change while static linking might depend on a change of the function offset in the library.

For example, static libraries might be loaded in runtime into the address space of the process at an static offset. Of course, knowing this offset allows for certain optimizations but if you update the library then either you update ALL the plugins using that library or probably the unupdated plugins won't work (as function offset might very well have changed).

I assume you load them in runtime, although if that can be named static linking is in the air, in any other case you will just have the library on each plugin and there will be no "sharing".