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(a)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(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev