5 ms·

Personal end user perspective: troubleshooting dylib errors is the most common cause of wanting to throw the computer out the window and quit programming.

cratermoon 5y ago
See also: DLL Hell in Windows and, more generally Dependency Hell. Dynamic linking errors are a subset of general dependency problems.
- spacechild1 5y ago
  As others have already mentioned elsewhere, DLL hell hasn't really been a thing anymore on Windows for years. I personally can remember it, but that's more than 15 years ago.
  - cratermoon 5y ago
    It's true, but only because every app essentially isolates itself from the system and carries around its own dependency bundle. I guess that's kind of what Docker containers are, so it's hard to be critical.
eqvinox 5y ago
"end user perspective" + "quit programming"? Do you troubleshoot dylib errors on your regular end user software and just happen to be a programmer unrelated to that? (If you're troubleshooting dylib errors on things you're developing, that's not an end user perspective?)
- dizzy3gg 5y ago
  End user of a linker?
  - rewma 5y ago
    > End user of a linker? I'd argue that if you're not packaging your software or testing your software's dependencies, either you're doing something extremely exotic that lies far outside anyone's happy path or "dylib error" should not even be a keyword in your vocabulary.
    - alisonkisk 5y ago
      The windows version, DLL Hell, is well known to non programmers.
    - pjc50 5y ago
      Roughly the same thing happens on Windows and is called "DLL hell", occasionally witnessed by end users.
      - rewma 5y ago
        DLL Hell ceased to be a practical concern over a decade ago, particularly given that Windows provides tight control over its dynamic linking search order. https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-... DLL Hell is not a linking problem, it's a packaging problem.
- gbear605 5y ago
  There’s a middle level of “troubleshooting dylib errors on open source software I’m installing for personal use because I’m a masochist who isn’t happy with closed source software”
  - eqvinox 5y ago
    Not sure that's a solvable problem, or even a problem that should be solved. It's the distributions' job to create packages to build a working whole system. If you decide to take that on yourself… I mean… yeah, you gotta learn how to handle DSO issues. Because you decided you want to do it yourself. I don't think I've ever run into DSO problems with any reasonable distro packaging (which, in this case, excludes old Gentoo — current Gentoo doesn't have those problems anymore either.)
    - AnIdiotOnTheNet 5y ago
      But if the distro doesn't package software you want to use, either because it only has an out of date version, modified version, or was just never packaged, then you're left dealing with this nonsense. In saner OS's where they don't rely on unpaid third party middlemen between the developer and the user this is rarely a problem.
      - cratermoon 5y ago
        > In saner OS's where they don't rely on unpaid third party middlemen between the developer and the user this is rarely a problem. Windows seems to fit your criteria for an OS without unpaid third parties, and there still exists a thing known as DLL Hell.
        spacechild1 5y ago
        I haven't really encountered DLL hell in Windows for the last 15 years or so. Most apps simply bundle all their dependencies locally and don't install them system wide.
- salawat 5y ago
  Yes. If you've never had a clashing Debian package build before, you've not been paying attention. I've made it my mission in life to try to get people more aware of linkers, and the fact that when you build something the one way it works on your system it doesn't mean it will work that way on someone else's.
  - eqvinox 5y ago
    I've never had a clashing Debian package build before, and I build quite a few Debian packages. Some for a wider audience and some for my own use. All packages that leave the confines of my own systems are built the "correct" way, in a clean minimal chroot with sbuild/schroot/cowbuilder. The docs on how to set that up are pretty good, and after you've done it once it's pretty easy to repeat for extra target distros (e.g. older Debian, Ubuntu.) What would you point out to me as part of your mission? [Just to be clear, a package is a package for a particular target distro. There's no such thing as "a .deb for software XYZ". Only "a buster .deb for software XYZ", or "a bullseye .deb for software XYZ", etc.]

cratermoon 5y ago

See also: DLL Hell in Windows and, more generally Dependency Hell. Dynamic linking errors are a subset of general dependency problems.

spacechild1 5y ago
As others have already mentioned elsewhere, DLL hell hasn't really been a thing anymore on Windows for years. I personally can remember it, but that's more than 15 years ago.
- cratermoon 5y ago
  It's true, but only because every app essentially isolates itself from the system and carries around its own dependency bundle. I guess that's kind of what Docker containers are, so it's hard to be critical.

eqvinox 5y ago

"end user perspective" + "quit programming"? Do you troubleshoot dylib errors on your regular end user software and just happen to be a programmer unrelated to that? (If you're troubleshooting dylib errors on things you're developing, that's not an end user perspective?)

dizzy3gg 5y ago
End user of a linker?
- rewma 5y ago
  > End user of a linker? I'd argue that if you're not packaging your software or testing your software's dependencies, either you're doing something extremely exotic that lies far outside anyone's happy path or "dylib error" should not even be a keyword in your vocabulary.
  - alisonkisk 5y ago
    The windows version, DLL Hell, is well known to non programmers.
  - pjc50 5y ago
    Roughly the same thing happens on Windows and is called "DLL hell", occasionally witnessed by end users.
    - rewma 5y ago
      DLL Hell ceased to be a practical concern over a decade ago, particularly given that Windows provides tight control over its dynamic linking search order. https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-... DLL Hell is not a linking problem, it's a packaging problem.
gbear605 5y ago
There’s a middle level of “troubleshooting dylib errors on open source software I’m installing for personal use because I’m a masochist who isn’t happy with closed source software”
- eqvinox 5y ago
  Not sure that's a solvable problem, or even a problem that should be solved. It's the distributions' job to create packages to build a working whole system. If you decide to take that on yourself… I mean… yeah, you gotta learn how to handle DSO issues. Because you decided you want to do it yourself. I don't think I've ever run into DSO problems with any reasonable distro packaging (which, in this case, excludes old Gentoo — current Gentoo doesn't have those problems anymore either.)
  - AnIdiotOnTheNet 5y ago
    But if the distro doesn't package software you want to use, either because it only has an out of date version, modified version, or was just never packaged, then you're left dealing with this nonsense. In saner OS's where they don't rely on unpaid third party middlemen between the developer and the user this is rarely a problem.
    - cratermoon 5y ago
      > In saner OS's where they don't rely on unpaid third party middlemen between the developer and the user this is rarely a problem. Windows seems to fit your criteria for an OS without unpaid third parties, and there still exists a thing known as DLL Hell.
      - spacechild1 5y ago
        I haven't really encountered DLL hell in Windows for the last 15 years or so. Most apps simply bundle all their dependencies locally and don't install them system wide.
salawat 5y ago
Yes. If you've never had a clashing Debian package build before, you've not been paying attention. I've made it my mission in life to try to get people more aware of linkers, and the fact that when you build something the one way it works on your system it doesn't mean it will work that way on someone else's.
- eqvinox 5y ago
  I've never had a clashing Debian package build before, and I build quite a few Debian packages. Some for a wider audience and some for my own use. All packages that leave the confines of my own systems are built the "correct" way, in a clean minimal chroot with sbuild/schroot/cowbuilder. The docs on how to set that up are pretty good, and after you've done it once it's pretty easy to repeat for extra target distros (e.g. older Debian, Ubuntu.) What would you point out to me as part of your mission? [Just to be clear, a package is a package for a particular target distro. There's no such thing as "a .deb for software XYZ". Only "a buster .deb for software XYZ", or "a bullseye .deb for software XYZ", etc.]