So does dynamic linking make sense after all or you mean link everything statically? Or do you mean that everything is made dynamic and if they(SFG,SFML) match they use same one and if not they have they own each?
You can see the full discussion
here. (and/or below or above)
I really hope Laurent can figure out a way to make it useful for both parties soon...
Windows makes this really confusing. On linux everything works out of the box as dynamic and I've yet to have linking problem. Can't the same be done for Windows?(everything dynamic so if few dlls use certain lib they each use same dll instead of each linking in own lib).
Yes you could, if you'd start a packaging service as for all the distros, but it probably would never resolve itself, because all the existing applications would have to start using your package service, otherwise they'll still just be shipping their own DLL version etc.
The concept on Windows is really not
that different from Linux's one (as far as I understand things), the issue is simply, that Windows didn't support different versions of DLLs in the past. It now somewhat does, but nobody really knows how. And this version issue led to the situation where we are now. Everyone ships their own version, to make sure that everything works.
There should be a linking tutorial or something, this gets really hellish on windows. What if I have exe and my engine dll or lib which both use SFML, SFG and Lua? Do I link all dynamically or statically to both? Lua when it was linked statically before I moved to Linux to write was causing problems in visual so I guess dynamically?
I usually go with the rule, either go static or dynamic. Starting to mix things is quite dangerous and with SFML even more, since this exactly where the issue comes into play. When linking statically you link the libraries all in the final application, so if library A is using SFML and exe B is using SFML, SFML will only be linked in exe B and library A will automatically be able to use it as well. What now SFML does when linking statically is, it
includes GLEW into its static library, thus if you link against SFML and GLEW in your exe B, you'll end up with two different GLEW versions, which may or may not let the linker or compiler explode...