DLL Hell is something entirely different. The term comes from a time where Windows installers actually installed an applications required libraries in the "system location". So if application Foo is installed, and uses library Bar version N, but then you install application Baz, and it uses library B version N+M, suddenly Foo no longer works.

Modern "application bundle" approaches don't do this, because they keep any required shared (i.e. non-statically linked) libraries private to the application (bundle). This is what MacOS has done since its inception, and it has never suffered from DLL Hell.

The one notable downside is when there are vulnerabilities discovered in code ... the "traditional" Linux approach means that a system update can fix all applications in one step, whereas the bundle approach breaks this.


On Sat, Dec 9, 2017 at 8:37 AM, Gordonjcp <gordonjcp@gjcp.net> wrote:
On Sat, Dec 09, 2017 at 02:24:37PM +0100, Louigi Verona wrote:
> This is a good point, Fons.
>
> On Windows it is typical to bundle a program with stable libraries and
> dependencies. Is this strategy thinkable on FLOSS systems?

No, and it's a stupid idea on Windows too, which is why Windows uniquely
suffers from "DLL Hell".

Just write your software so it doesn't break APIs.

--
Gordonjcp

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev