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 <keybou...@gmail.com> wrote:
On 2017-03-05, at 9:49 AM, Brandon Allbery <allber...@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)?
