5 ms·

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 A

by DeepDuh 14y ago

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.

dman 14y ago
Shipping security fixes in core libraries is easier this way.
haberman 14y ago
> Why are most open source programs dynamically linked again? 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!
- deleted 14y ago
  [deleted]
- akavel 14y ago
  "I tend to think the drawbacks of dynamic linking outweigh the advantages for many (most?) applications." -- John Carmack "Dynamic linking considered harmful": http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols 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 http://www.akkadia.org/drepper/no_static_linking.html
- coffeeaddicted 14y ago
  Maybe the problem is saying all programs have to behave the same. It would indeed be irritating to have every unix-tool link to it's own libraries. But most well-known tools are small programs that don't get constant feature updates. But it's a whole different thing for typical desktop applications. Those are often way more often updated than the distros and there's no 2 distros out there having the same library versions which might be needed for an app to run. Still distros do not like if such applications use separate library versions... and that just doesn't work so well except maybe for the handful of high-profile applications which have enough maintainers. I mean even keeping an up-to-date Iceweasel on Debian already caused me trouble with library dependencies just some months ago - and that is probably the most prominent desktop application in the free software world. 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).
- mibbitier 14y ago
  Bandwidth is cheap. Memory and disk space are cheap. 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
  - option_greek 14y ago
    Not on every system. Not even on most systems. Embedded, mobile etc still benefit from low distro size.
  - grimboy 14y ago
    Cache memory is still not cheap.
othermaciej 14y ago
OS X apps are not generally statically linked. They are dynamically linked. But Apple almost never breaks binary compatibility of the public APIs.
- seanmcdirmid 14y ago
  Strong versioning is key. Only allow links to be redirected to bug fixes, never feature enhancements. If you wrote your code for 1.0, you'll continue to link against 1.0, barring some bug fix (1.0.1). Your code should never be silently upgraded to link against 1.1. Microsoft also gets this right with the global assembly cache. As an aside, DLL Hell was coined by Szyperski, who still works for Microsoft.
- mistercow 14y ago
  >But Apple almost never breaks binary compatibility of the public APIs. Technically no, not binary compatibility. But practical compatibility? Woo boy do they ever.
  - deleted 14y ago
    [deleted]
- DeepDuh 14y ago
  Well they are dynamically linked but usually only to Apple provided libraries as far as I know. It's not like every app installs a dozen new dlls to your system and that's what makes the big difference. It's what makes Mac apps (at least traditionally) standalone and executable from anywhere. 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.
  - natesm 14y ago
    Technically, outside of Apple frameworks, they're typically dynamically linked to frameworks located inside the .app folder. This is by no means mandatory though.
cooldeal 14y ago
>Why are most open source programs dynamically linked again? 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. http://linux.slashdot.org/comments.pl?sid=3079259&cid=41164967 http://linux.slashdot.org/comments.pl?sid=3079259&cid=41...
- jeremyjh 14y ago
  This is incomprehensible. "DLL Hell" is what happens you use dynamically linked libraries without managing versions and compatibility correctly. DLL Hell can only happen when you are doing dynamic linking so I'm not sure what you can possibly mean that dynamic linking "guards against perceived 'DLL hell'".
  - cooldeal 14y ago
    I meant the DLL hell that is made fun of, in Windows and seen as a bad thing. It was fixed in Windows by having 'Side by side' assemblies (SxS). http://en.wikipedia.org/wiki/Side-by-side_assembly http://en.wikipedia.org/wiki/Side-by-side_assembly The user does not see any problems except hard disk use(or perhaps a little slowness?) or when the filesystem breaks.
    - DeepDuh 14y ago
      Oh boy SxS. So now you have seperate DLLs for every application. How about just linking it in statically and make the applications standalone?
      - deleted 14y ago
        [deleted]
      - cooldeal 14y ago
        Sigh, sneering and snark and also downvotes on my GP comment. That's HN I guess. Must.. resist.. temptation.. to be snarky myself. 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?
Zev 14y ago
If only Apple wouldn't unnecessarily break their runtime environment every few releases. 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.

by DeepDuh 14y ago

dman 14y ago

Shipping security fixes in core libraries is easier this way.

haberman 14y ago

> Why are most open source programs dynamically linked again? 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!

deleted 14y ago
[deleted]
akavel 14y ago
"I tend to think the drawbacks of dynamic linking outweigh the advantages for many (most?) applications." -- John Carmack "Dynamic linking considered harmful": http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols 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 http://www.akkadia.org/drepper/no_static_linking.html
coffeeaddicted 14y ago
Maybe the problem is saying all programs have to behave the same. It would indeed be irritating to have every unix-tool link to it's own libraries. But most well-known tools are small programs that don't get constant feature updates. But it's a whole different thing for typical desktop applications. Those are often way more often updated than the distros and there's no 2 distros out there having the same library versions which might be needed for an app to run. Still distros do not like if such applications use separate library versions... and that just doesn't work so well except maybe for the handful of high-profile applications which have enough maintainers. I mean even keeping an up-to-date Iceweasel on Debian already caused me trouble with library dependencies just some months ago - and that is probably the most prominent desktop application in the free software world. 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).
mibbitier 14y ago
Bandwidth is cheap. Memory and disk space are cheap. 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
- option_greek 14y ago
  Not on every system. Not even on most systems. Embedded, mobile etc still benefit from low distro size.
- grimboy 14y ago
  Cache memory is still not cheap.

othermaciej 14y ago

OS X apps are not generally statically linked. They are dynamically linked. But Apple almost never breaks binary compatibility of the public APIs.

seanmcdirmid 14y ago
Strong versioning is key. Only allow links to be redirected to bug fixes, never feature enhancements. If you wrote your code for 1.0, you'll continue to link against 1.0, barring some bug fix (1.0.1). Your code should never be silently upgraded to link against 1.1. Microsoft also gets this right with the global assembly cache. As an aside, DLL Hell was coined by Szyperski, who still works for Microsoft.
mistercow 14y ago
>But Apple almost never breaks binary compatibility of the public APIs. Technically no, not binary compatibility. But practical compatibility? Woo boy do they ever.
- deleted 14y ago
  [deleted]
DeepDuh 14y ago
Well they are dynamically linked but usually only to Apple provided libraries as far as I know. It's not like every app installs a dozen new dlls to your system and that's what makes the big difference. It's what makes Mac apps (at least traditionally) standalone and executable from anywhere. 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.
- natesm 14y ago
  Technically, outside of Apple frameworks, they're typically dynamically linked to frameworks located inside the .app folder. This is by no means mandatory though.

cooldeal 14y ago

>Why are most open source programs dynamically linked again? 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. http://linux.slashdot.org/comments.pl?sid=3079259&cid=41164967 http://linux.slashdot.org/comments.pl?sid=3079259&cid=41...

jeremyjh 14y ago
This is incomprehensible. "DLL Hell" is what happens you use dynamically linked libraries without managing versions and compatibility correctly. DLL Hell can only happen when you are doing dynamic linking so I'm not sure what you can possibly mean that dynamic linking "guards against perceived 'DLL hell'".
- cooldeal 14y ago
  I meant the DLL hell that is made fun of, in Windows and seen as a bad thing. It was fixed in Windows by having 'Side by side' assemblies (SxS). http://en.wikipedia.org/wiki/Side-by-side_assembly http://en.wikipedia.org/wiki/Side-by-side_assembly The user does not see any problems except hard disk use(or perhaps a little slowness?) or when the filesystem breaks.
  - DeepDuh 14y ago
    Oh boy SxS. So now you have seperate DLLs for every application. How about just linking it in statically and make the applications standalone?
    - deleted 14y ago
      [deleted]
    - cooldeal 14y ago
      Sigh, sneering and snark and also downvotes on my GP comment. That's HN I guess. Must.. resist.. temptation.. to be snarky myself. 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?

Zev 14y ago

If only Apple wouldn't unnecessarily break their runtime environment every few releases. 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.