How does linking work on OS X

[Ondřej Čertík]

Hi,

I have an access to OS X 10.10 (Yosemite), I installed the default
XCode, and I managed to build a basic not so trivial profile:
https://gist.github.com/certik/3175503c8e1176771423, and everything
seems to work.

I am trying to figure out how the linking works, because rpath doesn't
seem to be used (though it is used in some packages apparently:
https://github.com/hashdist/hashstack/issues/726, why is that?). The
profile hd_base/lib only contains *.dylib, no *.so. Is my
understanding correct that if you link with such a dylib, the binary
will automatically have the full path to this dylib embedded in it
(similar to how rpath works on linux), so as a user you do not need to
set anything and things will just work. Is that why we need to set
rpath on linux, but nothing on OS X?

(As long as you do not move things around, but we cannot do that on
linux either yet.)

I just want to clarify that I understand it correctly.

Ondrej

[Aron Ahmadia]

On Mon, Apr 13, 2015 at 5:20 PM, Ondřej Čertík <ondrej...@gmail.com> wrote:

Is my
understanding correct that if you link with such a dylib, the binary
will automatically have the full path to this dylib embedded in it
(similar to how rpath works on linux), so as a user you do not need to
set anything and things will just work.

I don't think that's default behavior, but for whatever reason, we tend to get the correct thing out of autotools/CMake without setting/modifying flags.

A

[Volker Braun]

OSX has rpaths pretty much like linux, but the tools are all completely different. $prefix is named differently. Try "otool -l <dylibfile>" to get started.

[Francois Bissey]

As Aron said this is not automatic but usually works if you use libtools and
properly formed cmake rules.
OS X has two kind of dynamic objects:
.dylib are dynamic libraries
.bundle are “dynamic objects” (plugins and other)
On linux there is no distinctions between the two and everything is a “.so”.
OS X dynamic will load files in .so - otherwise sage on OS X wouldn’t
work.
A well formed dynamic object has a property called install_name and if it
is set everything should be all right when you link to other libraries or an
executable. libtools and cmake usually get this right, beware of other
build systems such as scons or custom made.
A few ticket to get familiar with failures of that scheme:
http://trac.sagemath.org/ticket/17588
http://trac.sagemath.org/ticket/16017
http://trac.sagemath.org/ticket/16044

So a few packages that have historical issue with install_name:
R
boost

Yosemite overall does a better job in the dynamic loading department
and a lack of install_name is not necessarily setting you up for failure
anymore, but there could still be some issues lurking here and there.

otool -L $some_object
is the command you want to inspect those properties.

François

> --
> You received this message because you are subscribed to the Google Groups "hashdist" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hashdist+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.