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

[stefano iacus]

On Aug 14, 2004, at 12:05 AM, Simon Urbanek wrote:

> 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.

Yes, absolutely.

> 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...

Well, I think that for the distributed binary we need to assume the 
"standard" location. The above works for me too.
I think we need to assume that binary distribution of both the 
application and the packages, is for average Mac users not aware of 
what a compiler is, nor an environment variable. So we need to provide 
an installer with the framework, the R.app and binary packages on CRAN 
should fit with this.
Expert users can build their versions of the the R.framework, of the 
R.app and the packages.


BTW, I've uploaded a new version (only the project, 214KB). I've 
implemented few things in due curse (tool bar, clickable history, etc) 
and I've re-implemented the buffered output writing asin the Carbon 
R.app, which speeds up the thing a lot. I still did not write the code 
for menus, but the whole setup seems ok to me.

To get it, go directly at http://www.economia.unimi.it/R/RApp.dmg   as 
I did not yet prepared a text on that page.

stefano

>
> 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
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac