Hacker News Reader

Comment by dhsysusbsjsi | Hacker News Reader

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

View on HN

"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?)

End user of a linker?

> 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.

Roughly the same thing happens on Windows and is called "DLL hell", occasionally witnessed by end users.

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-...

DLL Hell is not a linking problem, it's a packaging problem.

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”

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.)

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.

> 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.

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.

It's true, DLL Hell is mostly a thing of a past. The fact the Windows apps "fix" it by maintaining their own dependencies completely isolated from system-level libraries isn't exactly what I'd call a great solution. On the flip side, an application running in isolation from the system in a container including all the necessary dependencies is pretty much Docker, so maybe it's not terrible?

> The fact the Windows apps "fix" it by maintaining their own dependencies completely isolated from system-level libraries isn't exactly what I'd call a great solution.

Sadly ran into an issue with this today. A program I wanted to use I guess forgot to ship the dependencies in the provided binaries of most recent version. I could maybe track them down, but many of not all of them would have to be built from source, which I’d rather not bother with.

There’s nothing especially sane about combining and testing code for the first time ever from different maintainers who weren’t even talking to each other. I’m glad that we don’t have to hire anyone full-time to do that from scratch just for us.

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.

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.]

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

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.

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.

Reply on news.ycombinator.com