Interesting discussion, and I agree that being able to post edit the
paths in OS X is very useful (@executable being the equivalent to
$origin).

The major problem though is libtool, which does not support (ASAIK)
$ORIGIN.  Further, libtool uses the information in the dependencies' .la
files to set rpath for libraries up the chain.  This is where coot is
getting rpath set.  

Charles

-----Original Message-----
From: Mailing list for users of COOT Crystallographic Software
[mailto:[email protected]] On Behalf Of Clemens Vonrhein
Sent: 02 June 2009 14:33
To: [email protected]
Subject: Re: [COOT] use of RPATH in coot libraries

Hi Kevin,

On Tue, Jun 02, 2009 at 02:18:25PM +0100, Kevin Cowtan wrote:
> OK, that is pretty cool, looks like the correct technical solution for

> our relocatable binaries.

Yes - Peter did some great analysis of all this on Linux and OsX.

> I can see implementation problems. It looks to me as though this will 
> only work if you build in place. All the coot dependencies get built 
> in their own trees and the installed later. I suspect therefore that 
> the link step might not work, because the rpath will be wrong until 
> the binaries are shifted into place. Maybe that can be dealt with 
> using LD_LIBRARY_PATH while building (but I'm out of my depth here).

Yes probably ... sounds sensible.

> I also suspect the packagers will then be unhappy:
>  http://wiki.debian.org/RpathIssue

Yes: for packaging something into a proper distro system I wouldn't go
that way. But for a tar.gz file that just gets unpacked it is a
solution.

Cheers

Clemens

-- 

***************************************************************
* Clemens Vonrhein, Ph.D.     vonrhein AT GlobalPhasing DOT com
*
*  Global Phasing Ltd.
*  Sheraton House, Castle Park
*  Cambridge CB3 0AX, UK
*--------------------------------------------------------------
* BUSTER Development Group      (http://www.globalphasing.com)
***************************************************************
--
Scanned by iCritical.

Reply via email to