A question on dynamic linking / version-changing libraries

[Chris Jones]

Building statically is also a security nightmare.

If I have a dynamic libFoo.so, that a lot of other libraries and 
applications dynamically link against, that is suddenly found to have a 
major security bug, then once libFoo.so is updated I know everything 
else using it is also fixed. If instead it where a static libFoo.a then 
its a nightmare as you then have to make sure *everything* that could 
possibly have used it got updated. There are reasons we don't generally 
statically link anymore, and they are good reasons.

The reasons MP does not have anything like frameworks is simply because 
such an idea does not really exist in the Linux/OSS world and as MP is 
essentially just a packaging system for that, thats what we get. 
Theoretically, could such a system exist there ? yes, of course. Will it 
ever... Highly unlikely.

On 05/03/17 20:07, Dominik Reichardt wrote:
> Oh you can build stuff statically but that is a kind of manual work and not for MP to do.
>
>> On 5. Mar 2017, at 19:47, Michael <keybounce at gmail.com> wrote:
>>
>>
>>> On 2017-03-05, at 9:49 AM, Brandon Allbery <allbery.b at gmail.com> wrote:
>>> Also fixed-*path* libraries are part of the Mach-O format and the tooling does not exist to override this well...
>>
>> Is this why a program compiled against a brew installation of qt5 in /usr/opt won't work with a ports installation of qt5 in /opt/local, and visa-versa?
>>
>> Is there really no way around this -- no way to say "This program wants qt5 in whatever this system says is the local path of libraries"? No equivalent of $PATH for libraries?
>>
>> ... OK, is there any way - at all - to have a program compiled with either brew or ports that will run on an arbitrary OSX that might not have either? (i.e. -- fully built and contained)?
>>