He switched between the two terms so often I honestly thought he was saying the end users need to install all the development packages on their system to run any dynamically-linked SFML program on Linux. I assume FRex was similarly confused.
"Library" is easier to type than "Shared Object File" but yes... I was referring to the file containing the library object code.
To be honest, I still don't get the arguments for dynamic linking outside of multi-threaded applications. I've been using static for everything just so I don't have to worry about all these dependencies (except the LGPL ones). Is there some really compelling reason for dynamic linking that applies on Linux and Mac but not on Windows? Because "this 3rd party library might improve its implementation someday and you might get the benefit of that for free!" just doesn't sound like a good enough reason to complicate distribution and introduce potential compatibility problems.
Package managers... and GPL.
Windows doesn't have a decent and widely accepted package manager (yet). If you are lucky the installer will take care of installing the required runtimes but that is also all it does most of the time. Some highly advanced installers might also pull other dependencies from the internet and install them somewhere for you, but there isn't any central repository within the operating system where all installed programs and their dependencies are registered. As far as I know, there also (still) isn't a proper way of solving the compatibility issue between programs and the specific versions of libraries they depend on. If I browse through my program folders I tend to see .dlls shipped with them all with the same name and roughly the same size. The few bytes that are different is what breaks the whole idea behind sharing multiple DLLs between programs. Was a nice idea.... horrible implementation, hence, broken. Since you are inclined to ship the DLL you depend on with the program, you might as well static link it into the program if you can, the less files the better. The only thing that prevents many from doing this is the licensing restrictions that apply to those libraries dictating that you can only dynamic link (kind of like LGPL except proprietary).
With package managers and proper versioning, program A depends on library version X.Y.Z, program B depends on the same library version X.Y, hence they can share the shared object file and it doesn't need to be reinstalled somewhere else. They don't need to be identical as is common practice in Windows (yes, even a minor version number change can break things so better stay safe, many developers didn't understand the notion of binary compatibility I guess). If you know that your library probably won't be used by any other program, there really is no space advantage, so static linking is just as good in that respect.
In the end, if you want to install awesome_game_9000 on Linux, you will do something like apt-get install awesome_game_9000 and apt will take care of the rest. Whether you static link or dynamic link doesn't really matter for the end user, since they will run it and it will work. If only your program uses the library, they also won't notice any difference in disk space taken up assuming you didn't compress the binary files in anyway (static linking might yield better compression than compressing 2 separate binary files).
For development I always static link. It is way easier to use standard profiling tools such as gprof when all the symbols are in a single file, be it on Linux or Windows.
