> On 6 Mar 2017, at 09:53, Chris Jones <[email protected]> wrote: > > > 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. >
Good point. Thank you. I’m providing OS X snapshots for a couple of game things and linking statically is the best I have come up with and these don’t have such security concerns but I’ll keep that in mind. > 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 <[email protected]> wrote: >>> >>> >>>> On 2017-03-05, at 9:49 AM, Brandon Allbery <[email protected]> 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)? >>>
