[R-SIG-Mac] R/Cocoa and DYLD_LIBRARY_PATH

[Simon Urbanek]

On Aug 13, 2004, at 9:53 PM, Byron Ellis wrote:

> So, I've been playing around with the R/Cocoa that Stefano posted and 
> I think I have a reasonable solution to the DYLD_LIBRARY_PATH problem.
> [...]
> To get around this problem in my personal install I went through (by 
> hand *sigh*) and used install_name_tool to change libR.dylib to 
> /Library/Frameworks/R.framework/Versions/2.0.0/lib/libR.dylib. This 
> seems to do the trick and it seems like it would be pretty easy to add 
> to the install process.

Well, the problem here is that the missing full path is actually 
deliberate. The fact that newly compiled packages have the full path 
could be considered a bug. The original idea was to allow relocatable 
R.framework. In fact the first framework builds of R contained the full 
paths and we fixed it to make it more flexible (thought the 
post-install linking is not fixed yet).

I'm still not sure if all R users can have write access to 
/Library/Frameworks (our default fixed location), so I think the 
relocation is a good idea. The main problem is due to the binary 
distribution - regular Mac users don't even have dev tools installed, 
so they'll use pre-compiled binaries and using fixed paths in binaries 
has its issues.

So what are the options? Using a stub that sets all appropriate 
variables ... well I hope that we can do without it, but it's 
definitely the ultima ratio. Should we use environment.plist? Well, 
that would solve it for specific users, but that's probably not a good 
idea in most multi-user environments. Should we set the variable 
globally? Theoretically this could affect some other applications and 
practically it makes the use of multiple R versions rather cumbersome.

IMHO the optimal solution is to use LSEnvironment dictionary in the 
bundle - this allows us to set the path directly in the .app. This has 
one big benefit: the app will determine which framework will be used. 
This way you can have multiple apps, each using a different framework 
even though the binary is the same. Personally I'd supply R_HOME, too, 
to avoid the hacks for determining R_HOME from the used library. I 
think this solution is quite clean and allows relocatable framework (of 
course we'll have to fix the compiling of new packages so it doesn't 
use the full path).

This is an example from the Info.plist of my RCocoa.app that works:
         <key>LSEnvironment</key>
         <dict>
                 <key>R_HOME</key>
                 
<string>/Library/Frameworks/R.framework/Resources</string>
                 <key>DYLD_FALLBACK_LIBRARY_PATH</key>
                 
<string>/Library/Frameworks/R.framework/Resources/bin</string>
                 <key>DYLD_LIBRARY_PATH</key>
                 
<string>/Library/Frameworks/R.framework/Resources/bin</string>
         </dict>
In practice we may want to use the full absolute paths during the 
installation of RCocoa.app - the above simply takes the "Current" 
version - dunno if that's what we'll supply in the end...

Cheers,
Simon

---
Simon Urbanek
Department of computer oriented statistics and data analysis
Universitätsstr. 14
86135 Augsburg
Germany

Tel: +49-821-598-2236
Fax: +49-821-598-2280

Simon.Urbanek at Math.Uni-Augsburg.de
http://simon.urbanek.info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3403 bytes
Desc: not available
Url : https://stat.ethz.ch/pipermail/r-sig-mac/attachments/20040814/87f089d3/attachment.bin