[R-SIG-Mac] R/Cocoa and DYLD_LIBRARY_PATH
simon.urbanek at math.uni-augsburg.de
Sat Aug 14 00:05:57 CEST 2004
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:
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...
Department of computer oriented statistics and data analysis
Simon.Urbanek at Math.Uni-Augsburg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 3403 bytes
Desc: not available
Url : https://stat.ethz.ch/pipermail/r-sig-mac/attachments/20040814/87f089d3/attachment.bin
More information about the R-SIG-Mac