[Rivet] dyld_library_path

[Andy Buckley]

James Monk wrote:
> I think I can shed some more light on this now:
> 
> The dynamic linker used by os X is not dlopen but is a thing called dyld:
...

> I have read (and it sounds reasonable) that .dylib files are shared
> libraries and .so files are loadable modules (that cannot be linked to).
> 
>     http://finkproject.org/doc/porting/shared.php

> So it sounds like we want those .so files to actually be dylibs (same
> goes for David probably).

Is that the right way round? Don't we actually want the dylibs to be .so's so
that they can be dlopened?

It's annoying that they can't be linked to: this is the whole reason for the
separation of the AGILe interface libraries into libAGILe<Gen>.so and
libAGILe<Gen>Mod.so. If it wasn't for this I'd just have one library for each
generator interface.

 > Hopefully, this means that all I have to do to get the dynamically
> loading version going is just change the library extension in Rivet and
> Gun (I see you already have a todo in the code for this in Rivet but not
> Gun).  I'm assuming AC_PROG_LIBTOOL defines the extension that is used
> by the system, so I just need to find and use that.

Great - let me know how that goes. Thanks :)

> One other thing
> that may be a problem is os x uses the full path to the library, I don't
> know how linux is doing it - but I'll cross that bridge if I come to it.

Linux looks it up in a variety of places if there aren't any "/" characters in
the string passed to dlopen(): rpath, runpath and LD_LIBRARY_PATH, I think. The
latter may be DYLD_LIBRARY_PATH on OS X. If there's a "/" in the name, it's
assumed to be an absolute path. From "man dlopen":

------
dlopen
       The function dlopen() loads the dynamic library file named by the
null-terminated string filename and returns an opaque "handle"  for  the
dynamic library.   If  filename is NULL, then the returned handle is for
the main program.  If filename contains a slash ("/"), then it is interpreted
as a (relative or absolute) pathname.  Otherwise, the dynamic linker searches
for the library as follows (see ld.so(8) for further details):

       o      (ELF only) If the executable file for the calling program
contains a DT_RPATH tag, and does not contain a DT_RUNPATH tag, then the
directories listed in the DT_RPATH tag are searched.

       o      If  the  environment  variable  LD_LIBRARY_PATH is defined to
contain a colon-separated list of directories, then these are searched.  (As a
security measure this variable is ignored for set-UID and set-GID programs.)

       o      (ELF only) If the executable file for the calling program
contains a DT_RUNPATH tag, then the directories listed in that tag are
searched.

       o      The cache file /etc/ld.so.cache (maintained by ldconfig(8)) is
checked to see whether it contains an entry for filename.

       o      The directories /lib and /usr/lib are searched (in that order).

       If the library has dependencies on other shared libraries, then these
are also automatically loaded by the dynamic linker  using  the  same  rules.
(This process may occur recursively, if those libraries in turn have
dependencies, and so on.)
------

Cheers,
Andy

-- 
Andy Buckley: CEDAR @ IPPP, Durham
Work: www.cedar.ac.uk
www.insectnation.org