A question on dynamic linking / version-changing libraries

[Brandon Allbery]

On Sun, Mar 5, 2017 at 1:47 PM, 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?
>

Partly. Also different build options making libraries even with the same
version not binary compatible, which would be an argument for static
linking if not for Apple deciding to pretend x86 is PPC.


> 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?
>

DYLD_LIBRARY_PATH... but this exact situation is also why DYLD_LIBRARY_PATH
can break your whole system and should not be used except as a last resort.
(Yes, I do mean "whole system" --- you can search for DYLD_LIBRARY_PATH in
MacPorts Trac and find instances of people breaking Apple-provided system
binaries... which is part of why Sierra prevents Apple binaries from using
that and other dyld envars via SIP. (Thereby causing other kinds of
breakage for various people... dyld envars are *extremely* blunt tools, and
so is SIP in many ways.)


> ... 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)?
>

Use something like Platypus to create an app bundle, and dylibbundler to
stow the needed dylibs in its Resources. Everything has to cart around its
own set of dylibs. And even then you have no guarantees, because something
like KDE uses tightly integrated IPC which relies on all those dylibs
agreeing on where things live and what format they have so a service daemon
autostarted by one of them will play nicely with the others regardless of
what environment they were built in (good luck with that! --- a KDE app
built by MacPorts will likely get indigestion from a HomeBrew ksycoca or
kdeinit, and vice versa, and *you cannot fix this with envars*, you have to
hack KDE source or at least synchronize build options).

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20170305/cb7517d0/attachment.html>