4 ms·

>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

>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?
      - DeepDuh 14y ago
        I can see the benefits in terms of security but not in terms of space. So what if the application folder uses half a gig more, if I never have to use installers for most applications. 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.
        option_greek 14y ago
        "So what if the application folder uses half a gig more, if I never have to use installers for most applications." Sure, but a gig more for RAM would make a lot of difference. http://en.wikipedia.org/wiki/Dynamic-link_library#Memory_management http://en.wikipedia.org/wiki/Dynamic-link_library#Memory_man...
        cooldeal 14y ago
        It looks like you don't know how manifests and SxS works. You can mark the DLL compatible while bumping the version number for security upgrades. The comments in this thread(from my OP) is a good start if you want to learn. http://linux.slashdot.org/comments.pl?sid=3079259&cid=41164967 http://linux.slashdot.org/comments.pl?sid=3079259&cid=41...
  - marshray 14y ago
    I'd take DLL hell over SxS hell any day of the week.
cdavid 14y ago
This rant makes little sense to me. Linking and COM are mostly orthogonal issues for once, and ABI compatibility in windows is not directly tight to COM. 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.

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?
    - DeepDuh 14y ago
      I can see the benefits in terms of security but not in terms of space. So what if the application folder uses half a gig more, if I never have to use installers for most applications. 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.
      - option_greek 14y ago
        "So what if the application folder uses half a gig more, if I never have to use installers for most applications." Sure, but a gig more for RAM would make a lot of difference. http://en.wikipedia.org/wiki/Dynamic-link_library#Memory_management http://en.wikipedia.org/wiki/Dynamic-link_library#Memory_man...
      - cooldeal 14y ago
        It looks like you don't know how manifests and SxS works. You can mark the DLL compatible while bumping the version number for security upgrades. The comments in this thread(from my OP) is a good start if you want to learn. http://linux.slashdot.org/comments.pl?sid=3079259&cid=41164967 http://linux.slashdot.org/comments.pl?sid=3079259&cid=41...
- marshray 14y ago
  I'd take DLL hell over SxS hell any day of the week.

cdavid 14y ago

This rant makes little sense to me. Linking and COM are mostly orthogonal issues for once, and ABI compatibility in windows is not directly tight to COM. 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.