Shared library grumble

[eekee]

I just installed wget in a Debian-based system, and then I found bash wouldn't start! There was some shared library version mismatch, I've lost the exact error. It's all fixed after "apt upgrade", but seriously, that's like recompiling the entire system; it has all the disadvantages except for time taken. As for time, what if I'd been using mobile data?

Every time I'm persuaded that shared libraries are not much trouble, something like this happens!

Is this just a failure of Debian package maintenance? Debian being open source and highly respected, I imagine they have one of the largest package management teams around; many eyes to watch for problems, so how did this slip through?

Okay, so someone's going to ask if I updated regularly. The answer is no, but seriously, that's not too different from recompiling the entire system.

[Octacone]

Shared libraries are crap! This happens to me all the time on KDE Neon.
God bless Windows and its simple .exe, which you double click to open, click install and all your troubles go away, no libraries, no crap.

There is an app called Qalculate, it is broken AF. Broken cyclic dependencies etc (lib1 requires lib2, lib2 requires lib3, lib3 requires lib1 v0.1.nonexistant, etc, impossible to fix).
So I used "snapd" to install it, which worked okay, except the app is mounted on a virtual HDD like wtf???

Code: Select all

/dev/loop9          0      0         1  1 /var/lib/snapd/snaps/qalculate_128.snap            0     512
/dev/loop7          0      0         1  1 /var/lib/snapd/snaps/qalculate_133.snap            0     512
/dev/loop5          0      0         1  1 /var/lib/snapd/snaps/qalculate_122.snap   

Like that, and it really messes my build system since a part of it relies on using those mountpoints, so I have to move my mountpoints all the fckn time every single reboot.
I just cannot express how much I hate some parts of Linux, but still how much I need it for osdev and how useful it is for coding...

[iansjack]

God bless Windows and its simple .exe, which you double click to open, click install and all your troubles go away, no libraries, no crap.

You really think that Windows doen't use shared libraries? Jeez!

[eekee]

Oh yeah, circular deps. I gave up helping with a Linux distribution on encountering a 5-package dependency loop including Xorg, some pdf or ps renderer, and some parts of Gtk+. I don't know if that one changed when they broke up Xorg, but the very fact that circular dependencies can arise implies to me there's no "big-picture" structuring going on.

Windows uses shared libraries, yes, I remember "dll hell", but they eventually realised they would have to kludge up some way to make it convenient. What you get now is numerous versions of all the shared libraries both in Windows dirs and program dirs.

The Linux field is all, "Technology will solve this for us," ignoring the vast hordes of slave labour needed to maintain the package tree! I'm exaggerating, but I think that's the essence of the problem.

[Octacone]

God bless Windows and its simple .exe, which you double click to open, click install and all your troubles go away, no libraries, no crap.

You really think that Windows doen't use shared libraries? Jeez!

At least they ain't broken.
Never had a single problem with them on Windows, even if there was, it was a super simple fix.
My dude you just cannot comprehend how many years of life I've lost due to Linux.

[deleted8917]

God bless Windows and its simple .exe, which you double click to open, click install and all your troubles go away, no libraries, no crap.

You really think that Windows doen't use shared libraries? Jeez!

At least they ain't broken.
Never had a single problem with them on Windows, even if there was, it was a super simple fix.
My dude you just cannot comprehend how many years of life I've lost due to Linux.

Eeeeh, do you forget about DLL hell?

[Schol-R-LEA]

Never had a single problem with them on Windows, even if there was, it was a super simple fix.
My dude you just cannot comprehend how many years of life I've lost due to Linux.

Eeeeh, do you forget about DLL hell?

I'm guessing that Octacone wasn't around to see the worst of it, which was in the early 1990s before the Registry was introduced in Windows 95 - though the bulk of the solution didn't really appear until Win98SE, as the initial Registry implementation left much to be desired.

DLL conflicts are still a major problem, but tend to get lost in the proliferation of even bigger and more visible problems - many of them caused by the Registry, so the cure has often been worse than the disease.

The job of managing dependencies, which is done by package managers in Linux (as core Linux doesn't have any such thing at all), is mostly done by the Registry in Windows. The main advantage for Windows is that there is exactly one type of Registry which is present in all Windows installations (for a given version of Windows, at least), which all developers can safely target without having to worry about having to support infinity minus one package managers with different distribution models (each of which might have multiple different implementations). The down side is that this same monoculture means that when it breaks or has a vulnerability, the problem occurs on every system, all at once.

Also, whereas in the Linux world, libraries are usually treated as separate entities, to be downloaded and installed as dependencies when needed but always treated as their own packages, in Windows they are usually seen as subordinate to the programs they are used by. As a result, many Windows programs tend to bypass the use of any DLLs which aren't part of either Windows itself (which make up about 75% of Windows, for the record, which is comparable to the composition of most Linux distros when the desktop manager is included) or Windows SDK, meaning that they tend to include a lot of redundant code which could be shared packages, but aren't.

This is also why most Windows installer packages include a copy of every third-party or bespoke DLL they need, and rely on the Registry to sort out which ones are already installed and the versions thereof. Prior to the introduction of the Windows Store, there was no easy way to distribute DLLs separately from the installers for the packages which use them, and even now it is generally more trouble than it is worth for the developers to try to use the WS as a way to get their dependencies distributed. By contrast, the majority of Linux package managers (of which there is a profusion, none of which are particularly good but most of which are superior to the WS, IMAO) work from the assumption that .so libraries are independent packages in their own right.

By no means am I saying that the Linux solutions (or the Mac OS solution, for that matter) are better; they simply suck in different ways. The fact that with most Linux distros almost any shared library can be treated as a 'just there' resource which will be automatically installed simply by including them in the dependency files has lead to a great deal of sloppiness in the handling of dependencies. Conversely, the number of different package file types, and the various flavors of each, has led to a great deal of confusion and redundant effort. Finally, there is always frustration involved when a given package is available in one package manager format but not others, or in a given format only from certain repositories. It's a trade-off.

Mind you, my plans for Kether involve a system in which everything is a shared library (sort of, it's TOCOTOX without derailing the thread even further) and every installation is a repo for all publicly visible programs and data currently cached on them (unless the admin explicitly disables torrenting), so my perspective is a little odd.

[iansjack]

It's instructive to look at just how many versions of the .NET Framework and Microsoft C++ redistributable libraries there are on a typical Windows installation, let alone other shared libraries.

[~]

Inspect the low-level assembly versions of the libraries you are needing, see where they reside in all of the library DLL files, and you'll know where to look at without ambiguity.

You may need to produce a dynamic-linking debug version of your program to figure out which libraries you need in case the code is copied into the EXE as a static-linking binary from LIBs, OBJs and the like.

[eekee]

The fact that with most Linux distros almost any shared library can be treated as a 'just there' resource which will be automatically installed simply by including them in the dependency files has lead to a great deal of sloppiness in the handling of dependencies.

I very much agree!

my plans for Kether involve a system in which everything is a shared library (sort of, it's TOCOTOX without derailing the thread even further)

To be honest, lately I've been getting a little nervous about how the components of my system will fit together, thinking I might run into similar problems to shared library versioning issues. It is a little early for me to be worrying about that though.