A question on dynamic linking / version-changing libraries
Dominik Reichardt
domiman at gmail.com
Mon Mar 6 09:24:23 UTC 2017
> On 6 Mar 2017, at 09:53, Chris Jones <jonesc at hep.phy.cam.ac.uk> 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 <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)?
>>>
More information about the macports-users
mailing list