Hi Folks, As a word from a dumb user / poor soul who has to maintain the installations, the fact that you can just unpack coot and it will work ANYWHERE is absolutely excellent. Despite the size and complexity of the package it was one of the simplest for me to do a central installation of here at Diamond!
Just in case anyone was seriously thinking about breaking this... Cheers, Graeme -----Original Message----- From: Mailing list for users of COOT Crystallographic Software [mailto:[email protected]] On Behalf Of Kevin Cowtan Sent: 02 June 2009 09:17 To: [email protected] Subject: Re: use of RPATH in coot libraries 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 This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
