Peter Keller wrote:
On Mon, 1 Jun 2009, Kevin Cowtan wrote:
OK, I understand, RPATH bad.
But as far as I can tell we don't use RPATH. Coot uses
LD_LIBRARY_PATH, which is only set by a wrapper script which launches
the actual binary, and so the use of LD_LIBRARY_PATH is never exposed
to the rest of the system (which I understand is the only problem with
LD_LIBRARY_PATH).
Not quite: if your application starts a subprocess and runs something
else, that subprocess will inherit LD_LIBRARY_PATH as set in the
wrapper. That
might be fatal for whatever you are running in the subprocess (unless it
too is invoked from a wrapper that overrides/unsets LD_LIBRARY_PATH).
On the whole, I prefer to use rpath, because it makes it easier to
harden an installation against the vagaries of what users have set in
their environment - using an rpath like '$ORIGIN/../lib' to set a path
relative to the location of the ELF can help with installation issues.
OS X and Solaris both allow editing of the runpath inside an executable,
so are streets ahead of Linux here.
Which breaks the (currently rather desirable) behaviour that you can
unpack our Coot packages anywhere you want and they will just work.
I can see that might work well for people packaging Coot for a Linux
distro, where it will always be installed in the same place, but it
doesn't work for us.
So we have two incompatible requirements on the build system for two
different situations. Given the complexity of the build system as it
stands, my suggestion is that you fork or replace it (although Paul may
have different views). I'm afraid I don't have the time or expertise to
get involved in that though.
K
