Linked by Thom Holwerda on Sun 15th Oct 2006 11:02 UTC, submitted by michuk
GNU, GPL, Open Source "There is one huge difference between the free and non-free software that has some very practical implications in the way we use it. One of those implications are the dependencies between single software packages in the free software model. What do they have to do with the free software philosophy and why should not you be afraid of them? Read on to find this out."
Thread beginning with comment 171871
To read all comments associated with this story, please click here.
Dependency hell comes down to linking ...
by MacTO on Sun 15th Oct 2006 15:29 UTC
MacTO
Member since:
2006-09-21

Yes, I know that there are at least two different types of dependency in the Linux world -- but I am going to focus on programs that link against external libraries.

There appear to be a few myths about libraries that are spread around by computer science types. And there were also a few myths added by this article. Let's look at the latter first:

1. Windows programs don't have external dependencies. Of course they have them. Windows developers simply know which components are a part of the operating system and which are likely to be a part of the operating system in the future (e.g. .Net). Windows developers also use libraries developed by third parties. It is just that they bundle the dynamic libraries with their software or use static linking. A well behaved application won't install those extra dynamic libraries as part of the system.

2. Dynamic libraries save disk space and memory. This is only true if a large number of programs use the same libraries. And I do mean a large number, because dynamic libraries are usually designed as general purpose libraries. That means that a lot of the code in the library will not be used by a given application. When you are using static linking, the linker can frequently figure out which code will not be used from a library, then discarde it. So it is not as though a statically linked program has to be excessively large.

3. Dynamic libraries can be updated to fix bugs and to add security patches. If there is a known bug with a library, third party developers will usually write their own code to work around that bug because they cannot necessarily wait for a bug-fix. A Linux box will frequently have several versions of the same libraries because of incompatabilities. Those old versions are rarely updated to account for bugs or security patches anyway. So this effect is limited.

Yes there are times when dynamic linking is good. Core operating system components that have a stable API is one such case because you can make extensive use of the shared code aspect and you can have updates without breaking stuff. Which, incidently, is what happens in the Windows world (for the most part). The Linux world doesn't fit into that model very well, which is why Linux is known as having dependency hell.

Edit: wrong choice of a word.

Edited 2006-10-15 15:30

Reply Score: 5

John Nilsson Member since:
2005-07-06

I can think of two "quick" fixes for the problems you outline in point 2 and 3.

2. Dynamic libraries are "bloated".
Re design how shared code are handled by the OS then. Just load those parts that would actually be used.

3. Packages ar too tightly coupled with specific versions of libraries.
This is a problem that has been solved for ages. Use design patterns to minimize coupling. F.ex. make package depend on interfaces instead of on ohter packages.

Reply Parent Score: 1

Temcat Member since:
2005-10-18

Too bad I cannot mod you up higher than 5.

Reply Parent Score: 1

Bending Unit Member since:
2005-07-06

Excellent post!

Reply Parent Score: 1

Ookaze Member since:
2005-11-14

1. Windows programs don't have external dependencies. Of course they have them. Windows developers simply know which components are a part of the operating system and which are likely to be a part of the operating system in the future (e.g. .Net). Windows developers also use libraries developed by third parties. It is just that they bundle the dynamic libraries with their software or use static linking. A well behaved application won't install those extra dynamic libraries as part of the system

This is plain wrong. DLL hell is a problem even on the latest Windows. That's one of the main reason why people install only one app on one Windows server (or at least, several programs from only one vendor : MS for example).
That's also one of the reasons why Windows breaks beyond recognition when you install too much programs on them, even if you uninstall them.

2. Dynamic libraries save disk space and memory. This is only true if a large number of programs use the same libraries

BS, this is true as soon as 2 programs use the same libraries, which means nearly always.

And I do mean a large number, because dynamic libraries are usually designed as general purpose libraries. That means that a lot of the code in the library will not be used by a given application

Wow. Where did you get such nonsense ? Not all libraries are libc, actually, very few are. Most libraries are mostly used, not everyone does generic game engines.
The lot of code not used will simply be swapped out, so there is no problem at all. Lazy loading is efficient too.

When you are using static linking, the linker can frequently figure out which code will not be used from a library, then discarde it. So it is not as though a statically linked program has to be excessively large

But yet, it has to be entirely loaded in memory, no things like lazy loading. And actually, even with GCC, you can do that with dynamic libraries too.

3. Dynamic libraries can be updated to fix bugs and to add security patches. If there is a known bug with a library, third party developers will usually write their own code to work around that bug because they cannot necessarily wait for a bug-fix

Which means every one of them will have to do it, and you will have to update everyone of these programs. Updating the library means only one package has to be updated.
To see the magnitude of the problem, just look at zlib : a huge number of apps depend on it. If I static compiled my apps against it, it would be a nightmare.

A Linux box will frequently have several versions of the same libraries because of incompatabilities. Those old versions are rarely updated to account for bugs or security patches anyway. So this effect is limited

This must be the worst of all you said. A Linux box will NOT have several versions of the same libraries because of incompatibilities, that's plain false.
There are a few well known libraries like that (berkeley db, libstdc++, openssl, ...). These just need a recompilation of the app dependant on it at worst.
Besides, this has NOTHING to do with security updates.
A security update in a library will not be incompatible with the previous unsecure version (even the latest security updates in OpenSSL didn't require any recompilation or dependant apps).
And the old version is updated to a new version, which will be then taken by all the apps automagically, ELF is designed for that.
I compile everything from source on my system, and the only different version of library I keep is for a closed source app (libstdc++ for Real codec).
And for an example of things that will instantly break with static compile : all KDE apps, and more generally, all C++ apps, and they would be HUGE if statically compiled. While right now, even mp3kult still works under the latest KDE.

Yes there are times when dynamic linking is good. Core operating system components that have a stable API is one such case because you can make extensive use of the shared code aspect and you can have updates without breaking stuff. Which, incidently, is what happens in the Windows world (for the most part). The Linux world doesn't fit into that model very well, which is why Linux is known as having dependency hell

So much FUD it's unbelievable. Linux OS are heavily dynamic linked, and it works far better than in the Windows world. Linux OS don't fubar after 6 months of use, servers install tons of apps without problems too, don't need reboot to install apps, ... And package management solves all the other problems of updates.

Reply Parent Score: 1