<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 5, 2017 at 1:47 PM, Michael <span dir="ltr"><<a href="mailto:keybounce@gmail.com" target="_blank">keybounce@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On 2017-03-05, at 9:49 AM, Brandon Allbery <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> wrote:<br>
> Also fixed-*path* libraries are part of the Mach-O format and the tooling does not exist to override this well...<br>
<br>
</span>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?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br></blockquote><div><br></div><div>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.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
... 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)?<br>
</blockquote></div><br>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).<br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh                               sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>                                  <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad        <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</div></div>