[Rivet] dyld_library_path

[James Monk]

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:

	http://developer.apple.com/releasenotes/DeveloperTools/RN-dyld/ 
index.html

However, they say they translate calls to dlopen into the appropriate  
dyld calls, so there should be no need for any code changes, other  
than making sure the right library extension is used.

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

N.B. I believe they are basing this on os x version 1 or 2, which is  
about 6 years old - specifically I think dlopen is now supported on  
dylibs through emulation/wrapping.

So it sounds like we want those .so files to actually be dylibs (same  
goes for David probably).  otool reports the .so file to be a  
"bundle, " while the dylib is a dylib, so that may be triggering the  
linker into different loading behaviour (i.e. .dylib = emulation  
mode, .so = native).   That would be why when I renamed FPythia.dylib  
to FPythia.so it found the file but could not load it.

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


On 5 Oct 2007, at 15:52, Andy Buckley wrote:

> That's interesting! Which libraries in particular?
>
> David Grellscheid recently told me that for the dlopen()'d  
> libraries in
> Herwig, the OS X build actually makes .so libs: this looks like a
> demonstration of the same effect. I/we need to know more before trying
> to make our dynamic loading cross-platform - by building and using
> Rivet(Gun) on any system other than Linux, you're entering untested  
> (and
> non-priority) territory!
>
>> In fact, if I copy libpythiaxxxx.dylib to libpythia.so then
>> it does find pythia as a generator option, but fails to actually load
>> the library.
>
> I've made no effort to be Mac compatible with dynamic loading at the
> moment, hence the library name lookup is always set to search for .so
> files. The DYLD_LIBRARY_PATH thing is a new one on me, but Rivet(Gun)
> doesn't explicitly search those paths anyway: in the Linux-centric  
> docs,
> for "LD_LIBRARY_PATH" read "LD_LIBRARY_PATH, or whichever env var is
> used as part of the dlopen() library path on your system". I'm also  
> not
> sure how portable our use of dlopen() is - that's the point of  
> LTDL, but
> that doesn't work for the Fortran generator loading.