[LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

[Markus Seeber]

On 12/09/2017 02:32 PM, nils wrote:
> Yes, that is possible and I wholeheartly lobby for that because library
> bugs and mismatches are common and could be avoided.
>
> Ardour does it and I do it in my own programs as well, or at least will
> if properly released. If you can copy a library into your source tree
> (Python in my case) why would depend to the external ecosystem?
>
> Some Linux distributions  (mostly very small and unknown though) do it
> already but the "way of forefathers", the shared library, is still stuck
> in peoples head.
No the "way of forefathers" was static linking.
>
> Bottom line: It turned out the Windows way of shipping all or most
> libs with the program is a really good way to compatibility.

Just employ static linking when sensible. There are less ways a linker can screw that up
during runtime and your application size will be even smaller since we have link time
optimization these days, startup time will be faster and run time may be faster.
Sure, if LGPL licensed libraries are used, this may be impossible but from a technical
standpoind dynamic linking for self containing application bundles does not make
sense unless you actually need to link dynamically (e.g. license requirements, plugins etc.).

The current way of bundling shared libraries with the application ist just a dirty workaround
for Problems that combines the worst parts of static and dynamic linking,
introduces bloat and solves problems that are mostly caused by employing dynamic
linking in the first place.

Yes I understand why people do it, yes it works and yes it solves social and resource problems
so that people can move on. But the real technical problem is not solved.

>
> On 12/09/2017 02:24 PM, 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?
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev at lists.linuxaudio.org
>> https://lists.linuxaudio.org/listinfo/linux-audio-dev
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev