'Re: [R-SIG-Mac] How to start two different versions of R on a Mac'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       r-sig-mac
Subject:    Re: [R-SIG-Mac] How to start two different versions of R on a Mac
From:       Simon Urbanek <simon.urbanek () r-project ! org>
Date:       2011-09-16 16:06:11
Message-ID: 8AD794CD-7546-43A1-A10D-B6FFBF1D5B0C () r-project ! org
[Download RAW message or body]

On Sep 16, 2011, at 11:56 AM, Simon Urbanek wrote:

> 
> On Sep 16, 2011, at 11:46 AM, Steve Lianoglou wrote:
> 
> > Hi Simon,
> > 
> > Thanks for the quick reply ... very informative.
> > 
> > I don't exactly follow on what the compiling issues are, though.
> > 
> > You said:
> > 
> > > The only remaining difference is compilation of packages which uses the R \
> > > framework and thus that does rely on the Current link. You have several choices \
> > > there - you can build R without a framework (that's how it's built on Linux and \
> > > some people prefer to use it that way on the Mac as well), or you can run it in \
> > > place or you can change the flags of your installed R to link libR directly. \
> > > Obviously, this only makes sense if you want to build packages in two different \
> > > R versions at exactly the same time ...
> > 
> > What do you mean by "running it in place" and "this only makes sense
> > if you want to build packages in two different R versions at exactly
> > the same time"?
> > 
> > Let's say I'm running R-devel in this "Kasper-fashion" and fire an
> > `install.packages('whatever', by='source')`, are you saying that the
> > package will be linking against the wrong libR?
> 
> Yes. The linking is done via "-framework R" so that does respect the Current \
> symlink. As I said in the previous e-mail one of the options is to go back to LIBR \
> = -L$(R_HOME)/lib$(R_ARCH) -lR -dylib_file \
> libRblas.dylib:$(R_HOME)/lib$(R_ARCH)/libRblas.dylib which is what R uses until you \
> install it into a framework. 
> 
> > Or is there a problem
> > if I'm running R-2.13 in one window, and R-devel in another, then I
> > try to make them install/compile packages at the same time? I mean,
> > that sounds like a weird scenario, and I'm not sure why that would
> > matter anyway, but I'm trying to make sense of the "exactly the same
> > time" thing here, too.
> > 
> 
> I meant that compiling is the only time when it matters, so you can set the symlink \
> properly only for one compilation but not for two in parallel. So let's say if you \
> set the symlink in the R script then it's safe in any scenario except for the case \
> where you run R-2.13 CMD INSTALL followed by R-devel CMD INSTALL before R-2.13 CMD \
> INSTALL finishes. 

Ok, just to be really explicit to avoid further confusion: 
If you want to use CRAN R builds in parallel then the safest approach is to modify \
the R script by: a) changing unversioned framework paths to versioned ones
*and*
b) set the Current symlink to the version that is being started

This is as safe as you can get with pre-built binaries, but it has the limitation I \
mentioned (no concurrent package compilation with different versions in parallel). \
All this will *only* work on the command line and you will still have issues with \
things that have been built on R with with non-versioned paths (i.e., CRAN) which \
include hard-coded paths (but this should be very rare).

For anything more safe you'll have to build R yourself (either without a framework or \
without installing it into a framework).

Cheers,
Simon

> 
> > 
> > 
> > 
> > On Fri, Sep 16, 2011 at 11:15 AM, Simon Urbanek
> > <simon.urbanek@r-project.org> wrote:
> > > Just a quick heads-up on that guide -- installing nightlies from tar balls has \
> > > some consequences you may want to be aware of. Most notably the installer \
> > > scripts in the .pkg make sure R architectures match your system, but if you \
> > > install the tar balls (which are designed for OS X 10.5) that will not be the \
> > > case. This is an issue for OS X 10.6 and 10.7 since they no longer support ppc. \
> > > If you really want to install the tar balls (there is no real reason to do so) \
> > > you should either know what you are doing or run the postflight script (As \
> > > root) *before* you mess with the Current link: \
> > > https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R-build/packaging/leopard/scripts/postflight
> > >  
> > > Note that the guide and the script you posted essentially does what I posted \
> > > here except it fails to mention the package compiling issues ;). 
> > > Cheers,
> > > Simon
> > > 
> > > 
> > > On Sep 16, 2011, at 11:03 AM, Steve Lianoglou wrote:
> > > 
> > > > Hi,
> > > > 
> > > > There is also a (somehow recent) post on the bioc-devel mailing list
> > > > from Kasper that can help here, too:
> > > > 
> > > > https://stat.ethz.ch/pipermail/bioc-devel/2011-July/002684.html
> > > > 
> > > > He assumes you've downloaded R-2.13 and and R-devel binaries from
> > > > r.research.att.net and install via the `tar fvxz R*.tar.gz -C /`
> > > > 
> > > > He then has a shell script (which you need to fix the line wrapping on
> > > > -- I provide fixed version as a gist below) that does some minor
> > > > surgery to symbolic links and changes some relative paths to absolute
> > > > ones in the various ".../Resources/bin/R" files.
> > > > 
> > > > At the end of the day, you will have R-2.13.1 installed and invokable
> > > > from the cmd line as "R" (or R-2.13), and the devel branch is
> > > > invokable as R-devel.
> > > > 
> > > > I just used that for the R-devel bits (ie, I commented out things that
> > > > have to do w/ R-2.13) and successfully compiled a mixed R/C package
> > > > from source in the R-devel that I just downloaded and "relinked". I
> > > > made a gist of the script from Kasper's post and commented out the
> > > > lines that were messing around with R-2.13 for now:
> > > > 
> > > > https://gist.github.com/1222291
> > > > 
> > > > Perhaps you will find it helpful and hopefully not too dangerous, but
> > > > use at your own risk, of course. Please be sure to read Kasper's
> > > > original post and don't just run the script I linked to in the gist
> > > > without understanding what it does. If there are any unintended
> > > > side-effects, you'll have to reinstall your R versions from scratch,
> > > > or fix your installed `.../Resources/bin/R` scripts by hand.
> > > > 
> > > > HTH,
> > > > -steve
> > > > 
> > > > 
> > > > On Fri, Sep 16, 2011 at 9:18 AM, Simon Urbanek
> > > > <simon.urbanek@r-project.org> wrote:
> > > > > 
> > > > > On Sep 16, 2011, at 12:57 AM, Hofert Jan Marius wrote:
> > > > > 
> > > > > > 
> > > > > > On 2011-09-16, at 02:30 , Simon Urbanek wrote:
> > > > > > 
> > > > > > > 
> > > > > > > On Sep 14, 2011, at 3:02 PM, Hofert Jan Marius wrote:
> > > > > > > 
> > > > > > > > Dear Simon,
> > > > > > > > 
> > > > > > > > thanks for your help, that clarified a lot.
> > > > > > > > As I could read it is not "recommended" to make the adjustment.
> > > > > > > > 
> > > > > > > > Can RSwitch be called from the command line? If so, one could at \
> > > > > > > > least create a command (or alias) "R-2.13" that first calls RSwitch \
> > > > > > > > and sets the version accordingly and then starts R. That would be \
> > > > > > > > quite convenient. 
> > > > > > > 
> > > > > > > Actually, it's the other way around - switching versions is trivial \
> > > > > > > from the command line simply using "ln" (see the FAQ) so obviously you \
> > > > > > > can do that in the script. RSwitch is just a wrapper that allows you to \
> > > > > > > do that from the GUI. But note that the issue is that the Current link \
> > > > > > > can only be correct for one version, so you can use one or the other \
> > > > > > > but not both at the same time. Setting R home to the versioned version \
> > > > > > > allows you to use both at the same time but some issues remain \
> > > > > > > (compiling packages etc.). 
> > > > > > > Cheers,
> > > > > > > Simon
> > > > > > 
> > > > > > Dear Simon,
> > > > > > 
> > > > > > thanks for helping.
> > > > > > 
> > > > > > I realized that setting it with ln is just a convenience [not having to \
> > > > > > click anything], but of course that does not imply that one can suddenly \
> > > > > > open two versions. I even tried and one runs into problems quite quickly. \
> > > > > > That's a pity, I have to admit that this is the first time that the Mac \
> > > > > > is not behaving nicely and inferior to Linux. I don't have Linux \
> > > > > > installed but as far as I know from Linux users, they can have multiple \
> > > > > > versions installed *and* work with them in parallel. As one can read on \
> > > > > > http://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Why-is-R_002ehome_0028_0029-not-versioned_003f \
> > > > > > : "The advanatage of this setup is that it is possible to install \
> > > > > > multiple R versions in parallel and they all will be fully functional \
> > > > > > ...". Obviously it is not an advantage in comparison to Linux systems. I \
> > > > > > was wondering about that, that's why I asked. 
> > > > > 
> > > > > I think you may have missed my first e-mail -- if you change the R home \
> > > > > path to the *versioned* path then your home is no longer dependent on the \
> > > > > Current link and thus you get the same setup as on Linux. 
> > > > > The only remaining difference is compilation of packages which uses the R \
> > > > > framework and thus that does rely on the Current link. You have several \
> > > > > choices there - you can build R without a framework (that's how it's built \
> > > > > on Linux and some people prefer to use it that way on the Mac as well), or \
> > > > > you can run it in place or you can change the flags of your installed R to \
> > > > > link libR directly. Obviously, this only makes sense if you want to build \
> > > > > packages in two different R versions at exactly the same time ... 
> > > > > Cheers,
> > > > > Simon
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > On 2011-09-14, at 20:39 , Simon Urbanek wrote:
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On Sep 14, 2011, at 2:25 PM, Hofert Jan Marius wrote:
> > > > > > > > > 
> > > > > > > > > > Dear expeRts,
> > > > > > > > > > 
> > > > > > > > > > I recently switched to emacs (aquamacs) and I am amazed by its \
> > > > > > > > > > capabilities. I used to use RSwitch to switch between R-2.13 and \
> > > > > > > > > > R-2.14. Since I am now able to start R in different frames of \
> > > > > > > > > > emacs, I was wondering if I can simply start R-2.13 in one frame \
> > > > > > > > > > and R-2.14 in another frame. 
> > > > > > > > > > On experimenting, the first thing I realized was that in a \
> > > > > > > > > > terminal, I only have "R", "R32" and "R64" available; so no \
> > > > > > > > > > "R-2.13.32bit", "R-2.14.32bit", "R-2.13.64bit", "R-2.14.64bit" \
> > > > > > > > > > [or similar]. If I start "R", it starts the version that RSwitch \
> > > > > > > > > > has selected. But that means I can't start different R versions \
> > > > > > > > > > at the same time... However, I know that it works on Linux, so is \
> > > > > > > > > > there a Mac solution, too? It would be nice if one is not \
> > > > > > > > > > required to use RSwitch but can simply choose in emacs which R \
> > > > > > > > > > version should be started. 
> > > > > > > > > > The first step seems to be to locate the different installed R \
> > > > > > > > > > versions, which should probably be in \
> > > > > > > > > > /Library/Frameworks/R.framework/Versions/2.13/Resources and \
> > > > > > > > > > /Library/Frameworks/R.framework/Versions/2.14/Resources. But if \
> > > > > > > > > > RSwitch points to R-2.14 and I start the R version in the former \
> > > > > > > > > > directory (so R-2.13), it starts R-2.14 anyway... 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > For the command-line R (and only the command line R!) you can \
> > > > > > > > > simply create a copy of the R launcher script and replace all \
> > > > > > > > > occurrences of the R home path with the full *versioned* home path, \
> > > > > > > > > so for example for 2.13 you would use something like 
> > > > > > > > > sed \
> > > > > > > > > 's:/Library/Frameworks/R.framework/Resources:/Library/Frameworks/R.framework/Versions/2.13/Resources:g' \
> > > > > > > > > R > R-2.13 
> > > > > > > > > This will make your R script independent of the current framework \
> > > > > > > > > version. However, note that some things will break - for example \
> > > > > > > > > you won't be able to compile packages properly. For details see the \
> > > > > > > > > FAQ: \
> > > > > > > > > http://r.research.att.com/bin/macosx/RMacOSX-FAQ.html#Why-is-R_002ehome_0028_0029-not-versioned_003f
> > > > > > > > >  
> > > > > > > > > Cheers,
> > > > > > > > > Simon
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > R-SIG-Mac mailing list
> > > > > R-SIG-Mac@r-project.org
> > > > > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > --
> > > > Steve Lianoglou
> > > > Graduate Student: Computational Systems Biology
> > > > > Memorial Sloan-Kettering Cancer Center
> > > > > Weill Medical College of Cornell University
> > > > Contact Info: http://cbio.mskcc.org/~lianos/contact
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> > 
> > -- 
> > Steve Lianoglou
> > Graduate Student: Computational Systems Biology
> > > Memorial Sloan-Kettering Cancer Center
> > > Weill Medical College of Cornell University
> > Contact Info: http://cbio.mskcc.org/~lianos/contact
> > 
> > 
> 

_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[prev in list] [next in list] [prev in thread] [next in thread] 