You raise a good point. Why are most open source programs dynamically linked again?
Static linking is one of the nice things about the OSX ecosystem. If only Apple wouldn't unnecessarily break their runtime environment every few releases.
Static linking is one of the nice things about the OSX ecosystem. If only Apple wouldn't unnecessarily break their runtime environment every few releases.
Probably because dynamically-linked binaries are smaller, use less memory (by avoiding duplication), and can get fixes or security updates without rebuilding or re-deploying. When you're a distro it hardly makes sense to ship a copy of libc inside every single binary. Any fix/update to libc would require re-downloading basically the whole system!
I think the days when it mattered are really coming to an end personally.
The amount of space (memory/disk/bandwidth) taken up by binary code is minuscule compared with data/video/streaming/games/etc etc
"Dynamic linking considered harmful": http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/versioned-...
OTOH, arguments of the other side, for proper polemics: "Static linking considered harmful": http://www.akkadia.org/drepper/no_static_linking.html
It's getting even stranger in the world of free games. When games need library fixes (very typical situation as games and engines are very interwoven), which are not yet in a distro (and won't be for some time because the library is for example not yet officially updated or maybe a certain patch simply won't be included). On a system like Windows it's no problem - modify the library source and add the dll. On Linux distro's... well, just not easy possible. Which means funny enough that it's easier to modify library sources in the in the proprietary microsoft world than in the free software world. We got freedom coming with library + distro gatekeepers so to say... which pretty much sucks (even for the library authors).
As an aside, DLL Hell was coined by Szyperski, who still works for Microsoft.
Technically no, not binary compatibility. But practical compatibility? Woo boy do they ever.
I fear however, that Apple is currently destroying this design philosophy with the sandboxing. At least the application data folders have become way more complex now and I wouldn't like to troubleshoot them anymore, something that has been always been super easy.
What runtime-breaking changes are you thinking of? Apple's been very good about not breaking the binary compatibility -- of the runtime, or of their frameworks between OS releases.
Sure, there are some differences in 64-bit systems from 32-bit systems. But, if you take a 32-bit Mac app from five years ago, and run it, it will still run just as well today as it did when it was first compiled.
To save on bloat of shipping multiple redundant libraries with every app and to guard against the perceived 'DLL hell' in Windows(which was fixed a decade ago). Ironic that ended up in 'Dependency hell' with RPMs and Apt packages requiring specific versions of libraries.
Read through this excellent discussion thread if you're really interested in the problems with linking and the lack of a Common Object Model in Linux.
The user does not see any problems except hard disk use(or perhaps a little slowness?) or when the filesystem breaks.
How about just linking it in statically and make the applications standalone?
Anyway back to the point...
>Oh boy SxS. So now you have seperate DLLs for every application.
No, only if the application uses a different version that explicitly is marked as NOT being compatible. If the version used is the same, you do not have separate DLLs for every application.
>How about just linking it in statically and make the applications standalone?
That will needlessly bloat up the application.
Assume 10 applications need library X version 2.3 and one application needs 2.2. With SxS, you will have one 2.3 DLL and one 2.2 DLL. If you link it statically, the same code will be duplicated in 10 EXEs. Multiply this by all applications and DLLs used across applications.Not to mention waiting fot 10 apps to update to fix a security bug.
You think that's good?
And as far as your example goes: From what I understand most Windows developers just use a fixed library version number to specify what dll to use. When that happens, security updates won't do any good either. IMO as long as APIs can be changed in between library versions, developers will always be responsible themselves to upgrade to the newest libraries. It's a nice idea but it just doesn't reflect the reality in the world of Business application where incompatibility directly result in monetary losses.
The comments in this thread(from my OP) is a good start if you want to learn.
Sure, but a gig more for RAM would make a lot of difference. http://en.wikipedia.org/wiki/Dynamic-link_library#Memory_man...
I think the lack of ABI compatibility in linux has more to do with incentive and economics: innovating while keeping ABI is very difficult and ressource-consuming. I don't understand why Miguel would cite Apple, as they are pretty lousy in that department, whereas MS famously spend tons of resources on that issue.