SoQt linking error on Mavericks (10.9.3)

Brandon Allbery allbery.b at gmail.com
Sat Jun 28 11:00:47 PDT 2014


On Sat, Jun 28, 2014 at 1:45 PM, Mark Brethen <mark.brethen at gmail.com>
wrote:

> Those are the install_names at build time of each respective port.


I think you're confused about install_name means.

Every link-time shared object contains a canonical name telling the dynamic
loader how to find the runtime version of the shared object. On OS X with
Mach-O, it's called "install_name" and is a full pathname; there is nothing
like ELF's "rpath", but there are special environment variables that
override the embedded locations (this is why people assuming that
DYLD_LIBRARY_PATH is like ELF-style LD_LIBRARY_PATH break their systems; it
doesn't behave the same way and can cause system-provided shared objects to
not be found or inappropriately replaced).

The install_name is therefore a special name embedded in a shared object
allowing it to be found at runtime. If this is not either a full path or a
bundle-relative path (which works *only* with bundles -- that is, things
like frameworks or the app bundles you find in /Applications; these start
with @ and a keyword), the dynamic loader won't be able to find the shared
object at runtime. Relative pathnames will not be found reliably, and the
default will be the build path --- which will almost always be incorrect,
because applications aren't normally run out of their build directories,
they are installed.

-- 
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: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140628/61f2f22a/attachment-0001.html>


More information about the macports-dev mailing list