[Rivet] dyld_library_path

[Andy Buckley]

[Another copy to the Rivet list for general interest]

James Monk wrote:
> Hi Andy,
> 
> I'm having a bit of trouble getting rivetgun (dynamic) to find analyses
> and generators.  How does RivetGun know where it is supposed to look? 
> It occurs to me that $LD_LIBRARY_PATH becomes $DYLD_LIBRARY_PATH under
> Darwin, and that might be causing it some problems, or perhaps similarly
> .so becomes .dylib (I notice that in the main program the generators are
> mapped to *.so files and it has installed the agile libs with .so
> suffixes!).

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.

> Sorry about causing you maccy problems!   It would probably be easier
> for me rather than you to get the mac dynamic version working (as I
> actually have access to one), but I don't really understand how the
> dynamic loading works, so I need to learn that before I can do it.

I suspect that's right. Can you could read around before changing
anything, though: I really want to know what the distinction is between
.dylib and .so on OS X and what build flags distinguish between the
built suffix.

If all dlopen()-able libraries should be .so's, then our bundled Fortran
generator libaries should also have the appropriate build flags added.
This would also mean that we don't need a global platform-specific
library suffix since .so would work for everything - you'll see a
template #define for that purpose in the Rivet pluggable analysis
loader, which I'd be happy to be able to remove! Windows compatibility
is quite another issue and I'm not going there...

Andy