I just wanted to go into details on something that came up in my chat
with Kenneth and Jens:
I believe that the ultimate in user-friendliness is to allow running
/path/to/your/binary
without worrying about the environment at all. For HPC, having to load
modules and LD_LIBRARY_PATH is just a minor inconvenience, but for
desktop users it can be a real hassle if you launch programs from GUIs,
have different software stacks in different shells and so on.
Also in extreme cases it can cause real problems, e.g., in my
university, I can't send a postscript file to the network printer from
within a Sage session, because the script to launch a print job depends
on libraries that conflicts with the ones in my LD_LIBRARY_PATH.
There are two tools that can help achieve this that I wanted to make you
aware of.
- patchelf: The way to avoid LD_LIBRARY_PATH is setting -Wl,-R
/path/to/lib when compiling, but that requires modifications to all
builds. An alternative is [http://nixos.org/patchelf.html] which will
patch the built binary/.so after the fact and set the RPATH, so that
this can be done in a post-processing step.
- ${ORIGIN}: To make the software relocatable on various disks etc.,
one can use a feature from modern "ld.so" (may not be available on old
Linux boxes etc.). This is from "man ld.so":
"""
RPATH TOKEN EXPANSION
The runtime linker provides a number of tokens that can be used
in an rpath specification (DT_RPATH or DT_RUNPATH).
$ORIGIN
ld.so understands the string $ORIGIN (or equivalently
${ORIGIN}) in an rpath specification to mean the directory containing
the application executable. Thus,
an application located in somedir/app could be compiled
with gcc -Wl,-rpath,'$ORIGIN/../lib' so that it finds an associated
shared library in somedir/lib no
matter where somedir is located in the directory hierarchy.
"""
Dag sverre
