As someone who has principally programmed for Linux and Unix, the reverse is true for me. Building and packaging for Linux and traditional Unix environments feels very straight forward and transparent to me, while building and packaging for Windows and (to a lesser extent) macOS seems like a dark art. And I think that's largely because "properly" built and packaged applications (particularly GUI applications) for those systems should use Visual Studio or XCode, which require learning and applying proprietary and restrictive (to me) build and link processes. And those processes are geared toward building and packaging dependencies together, whether linking dynamically or statically[1], which in the Unix universe was an anti-pattern to be avoided as much as possible.
More to the point, the phrase DLL Hell was literally coined by and for Windows developers to describe Windows-specific headaches. This much is a fact. A minority of people in the Unix universe use the term DLL, certainly in the 1990s when DLL Hell became a meme; the term shared library was and remains more common. The usage of DLL Hell in the general sense of exclaiming linking and packaging in a particular environment to be too complex and brittle is quite recent and uncommon, though increasing.
I did say alot of words, though :) It was late....
[1] Notably the Debian/Ubuntu universe rather strictly requires the packaging of statically linkable libraries. With rare exception the foo-dev package should always install a useable libfoo.a and, if supported, foo.a for module-based frameworks that permit static embedding, even if the upstream project only builds a shared library. This makes statically linking trivial without having to bundle your dependencies into your build; and makes it easier to stick to a policy of using system-installed dependencies, minimizing the risk of transitive dependency conflicts, even when statically linking, as the maintainers do the hard work of ensuring version compatibility holistically. Red Hat has a similar policy but in IME more poorly executed. On multiple occasions I've found RPM-packaged static libraries (including those built by Red Hat, such as liblua.a) to have been built with the wrong build flags, causing unnecessary namespace and linking headaches, sometimes forcing me to bundle the dependency directly into my build or creating a bespoke RPM package. More generally I've found the RPM universe to be much more inconsistent and problematic, and instead of fixing these technical and functional issues Red Hat expends most of their effort attempting to bypass, rather than complement, the RPM ecosystem. By contrast Debian and Ubuntu package maintainers do a better job of fixing broken upstream builds, which makes life easier for everybody. If I had the choice, I'd stick to supporting only Debian-based operating systems precisely for this reason.
In the windows universe though, that sort of bundling is not really necessary for large parts of what would constitute a GUI application in UNIX land, because the OS provides a guaranteed base set of libraries you can use.
I've been working with Zig a lot lately, and writing a GUI Windows app with no support from any MS tool was a simple matter of some DLL calls. I don't have to recompile for every version of Windows because they might have a different version of libfoo, or it might be under a different name, or any of that garbage.
Even if I did have a complicated set of library dependencies on top of the OS, I can just zip them up in a folder with my application and call it a day. In UNIX land, I'm expected to jump through a bunch of packaging hoops and make the user jump through hoops to get my package to avoid conflicts that may or may not exist. Even if I want to distribute my application as a straight AppDir, or with something like AppImage, I have to include a hell of a lot to cover things that any given distribution might screw me on, or make the user jump through hoops getting the right dependencies.
>More to the point, the phrase DLL Hell was literally coined by and for Windows developers to describe Windows-specific headaches
Yes, when everyone tried to copy their DLLs into the system folder and share them all UNIX style. There's a reason they don't really do that any more.
More to the point, the phrase DLL Hell was literally coined by and for Windows developers to describe Windows-specific headaches. This much is a fact. A minority of people in the Unix universe use the term DLL, certainly in the 1990s when DLL Hell became a meme; the term shared library was and remains more common. The usage of DLL Hell in the general sense of exclaiming linking and packaging in a particular environment to be too complex and brittle is quite recent and uncommon, though increasing.
I did say alot of words, though :) It was late....
[1] Notably the Debian/Ubuntu universe rather strictly requires the packaging of statically linkable libraries. With rare exception the foo-dev package should always install a useable libfoo.a and, if supported, foo.a for module-based frameworks that permit static embedding, even if the upstream project only builds a shared library. This makes statically linking trivial without having to bundle your dependencies into your build; and makes it easier to stick to a policy of using system-installed dependencies, minimizing the risk of transitive dependency conflicts, even when statically linking, as the maintainers do the hard work of ensuring version compatibility holistically. Red Hat has a similar policy but in IME more poorly executed. On multiple occasions I've found RPM-packaged static libraries (including those built by Red Hat, such as liblua.a) to have been built with the wrong build flags, causing unnecessary namespace and linking headaches, sometimes forcing me to bundle the dependency directly into my build or creating a bespoke RPM package. More generally I've found the RPM universe to be much more inconsistent and problematic, and instead of fixing these technical and functional issues Red Hat expends most of their effort attempting to bypass, rather than complement, the RPM ecosystem. By contrast Debian and Ubuntu package maintainers do a better job of fixing broken upstream builds, which makes life easier for everybody. If I had the choice, I'd stick to supporting only Debian-based operating systems precisely for this reason.