[Rcpp-devel] RInside under Windows
Patrick Burns
patrick at burns-stat.com
Thu Feb 16 12:00:35 CET 2012
Success.
I'll tentatively offer this summary of the
important things to do. There are three
environment variables to set:
* PATH needs to include the path to the R DLLs
for example the bin\i386 under your R_HOME.
* R_HOME needs to be set.
* R_LIBS_USER needs to be set. (Trying to do it
in .Rprofile didn't work for me.)
There is still a puzzle in my mind. Setting
R_LIBS_USER was necessary to get:
make -f Makefile.win
to work. Fine.
But when it is not set and the exe files already
exist, there is strange (to me) behavior. Double
clicking runs the code, but running it in a
command window does not. Essentially R_LIBS_USER
is okay in the double click route but the environment
variable is necessary when run in a command window.
Pat
On 15/02/2012 14:03, Dirk Eddelbuettel wrote:
>
> On 15 February 2012 at 11:14, Patrick Burns wrote:
> | Dirk is once again correct. The "missing R.dll"
> | is a PATH problem.
> |
> | One way of solving it is to add the path to the
> | R DLLs to the end of PATH. For instance adding:
> |
> | C:\Program Files\R\R-2.14.1\bin\i386
> |
> | Once I've arranged those DLLs to be visible, the
> | new problem is:
> |
> | Fatal error: unable to open the base package
>
> If I recall correctly I solved that by setting R_HOME as
> your embedded R interpreter doesn't know its location...
>
> Dirk
>
> | That seems like it might be a path problem as well
> | but I'm not seeing how to fix it.
> |
> | Pat
> |
> | On 14/02/2012 21:52, Dirk Eddelbuettel wrote:
> |>
> |> On 14 February 2012 at 21:05, Patrick Burns wrote:
> |> | On 14/02/2012 20:59, Dirk Eddelbuettel wrote:
> |> |>
> |> |> (resending with CC to list which I omitted a minute ago --Dirk)
> |> |>
> |> |> On 14 February 2012 at 20:47, Patrick Burns wrote:
> |> |> |
> |> |> |
> |> |> | On 14/02/2012 20:14, Dirk Eddelbuettel wrote:
> |> |> |>
> |> |> |> On 14 February 2012 at 20:04, Patrick Burns wrote:
> |> |> |> | Obviously I don't *really* know what I'm
> |> |> |> | doing, or even *sort of* know what I'm
> |> |> |> | doing. But that never stopped me before.
> |> |> |> |
> |> |> |> | Here is hopefully enough breadcrumbs to
> |> |> |> | help someone, or even all of us.
> |> |> |> |
> |> |> |> |
> |> |> |> | I've reinstalled RInside so that I am
> |> |> |> | starting with the original Makefile.win
> |> |> |> |
> |> |> |> | *) There is an extraneous "n" on the first
> |> |> |> | line (first character) of Makefile.win -- 'make'
> |> |> |> | doesn't like that.
> |> |> |>
> |> |> |> I don't know for sure what your are talking about. A common fix would be to
> |> |> |> send a diff. Could you do that?
> |> |> |
> |> |> | This is Windows, remember -- perhaps there is a
> |> |>
> |> |> This is R, remember, and these tools come with Rtools by Duncan Murdoch.
> |> |>
> |> |> | way of doing a diff, I don't know it. But the
> |> |> | start of Makefile.win that I see out of the box is:
> |> |> |
> |> |> | n## -*- mode: makefile; tab-width: 8; -*-
> |> |> | ##
> |> |> | ## Simple Makefile for Windows
> |> |> |
> |> |> | Note the bizarre first character.
> |> |>
> |> |> Got it. Was still present here. Sorry about that, and thanks for catching it.
> |> |>
> |> |> Next release will fix, now corrected in SVN.
> |> |>
> |> |> |> | *) I need to comment out the command setting
> |> |> |> | R_HOME and set it in DOS instead.
> |> |> |>
> |> |> |> Works for me in the Makefile.win
> |> |> |>
> |> |> |> | *) The next problem is two instances each of:
> |> |> |> |
> |> |> |> | there is no package called [Rcpp, RInside]
> |> |> |> |
> |> |> |> | This is because .libPaths() is only finding
> |> |> |> | the main library and not the one where the
> |> |> |> | installed packages go.
> |> |> |> |
> |> |> |> | This is diagnosed by adding a line to Makefile.win:
> |> |> |> |
> |> |> |> | Rlibpaths := $(shell echo '.libPaths()' | $(R_HOME)/bin/R $(R_ARCH)
> |> |> |> | --vanilla --slave)
> |> |> |>
> |> |> |> I would recommend using ~/.Rprofile which strikes me as easier.
> |> |> |>
> |> |> |> | Adding a line to the checkR task:
> |> |> |> |
> |> |> |> | echo $(Rlibpaths)
> |> |> |> |
> |> |> |> | And then doing:
> |> |> |> |
> |> |> |> | make checkR -f Makefile.win
> |> |> |> |
> |> |> |> | This is the same in 32-bit and 64-bit.
> |> |> |> |
> |> |> |> | This problem can be remedied by setting the
> |> |> |> | R_LIBS_USER environment variable. You can
> |> |> |> | see what that is with the R command:
> |> |> |> |
> |> |> |> | Sys.getenv('R_LIBS_USER')
> |> |> |> |
> |> |> |> |
> |> |> |> | *) Now there is some progress, but not much.
> |> |> |> |
> |> |> |> | It compiles:
> |> |> |> | rinside_callbacks0
> |> |> |> | rinside_module_sample0
> |> |> |> | rinside_sample0
> |> |> |>
> |> |> |> Can you run rinside_sample0.exe ?
> |> |>
> |> |> Does that run?
> |> |
> |> | There is the missing R.dll problem.
> |>
> |> That is "just" a PATH problem. For now, copy this dll (and there will be
> |> four or five more from R, and then possibly from Rcpp and RInside) into a
> |> working (temp) directory and try.
> |>
> |> Seeing "hello, world" is a good proof. The rest is setup issues, which on
> |> Windows often descend into man-to-machine combat.
> |>
> |> Dirk
> |>
> |> |>
> |> |> |> | And gets an error on rinside_sample1:
> |> |> |> |
> |> |> |> | reopening rinside_sample1.exe: Permission denied
> |> |> |>
> |> |> |> Huh?
> |> |> |
> |> |> | Agreed. That is the only indication of it
> |> |> | being upset.
> |> |> |
> |> |> | But I renamed that file to try to make it do it last.
> |> |> | Running it again there was no error -- everything
> |> |> | compiled.
> |> |> |
> |> |> | Compiled for 32-bit.
> |> |> |
> |> |> | There is not an x64 subdirectory to 'lib' (as there is
> |> |> | with 'libs') so nothing compiles.
> |> |>
> |> |> Are you talking about RInside or Rcpp? Did you install from source or via
> |> |> the prebuilt CRAN binary?
> |> |>
> |> |> Everything from CRAN should now be multiarch, 32 and 64 bit.
> |> |
> |> | Prebuilt from CRAN. Rcpp is fine,
> |> | RInside/lib/x64 went AWOL.
> |> |
> |> | Pat
> |> |
> |> |>
> |> |> Dirk
> |> |>
> |> |> |> | However the three that did compile don't run. They
> |> |> |> | all have the error message:
> |> |> |> |
> |> |> |> | The program can't start because R.dll is missing from
> |> |> |> | your computer. Try reinstalling the program to fix
> |> |> |> | this problem.
> |> |> |>
> |> |> |> Could that be a Win7 security setting or something like it?
> |> |> |
> |> |> | That's an interesting idea. Anyone have
> |> |> | ideas about testing it?
> |> |> |
> |> |> | Pat
> |> |> |
> |> |> |>
> |> |> |> | This is using Rtools2.14 and R 2.14.1 with
> |> |> |> | RInside_0.2.6 Rcpp_0.9.9
> |> |> |>
> |> |> |> I think I used the same combination with success.
> |> |> |>
> |> |> |> Dirk
> |> |> |>
> |> |> |>
> |> |> |> | Pat
> |> |> |> |
> |> |> |> | On 14/02/2012 17:53, Dirk Eddelbuettel wrote:
> |> |> |> |>
> |> |> |> |> Hi Pat,
> |> |> |> |>
> |> |> |> |> On 14 February 2012 at 17:43, Patrick Burns wrote:
> |> |> |> |> | Good point about the Rtools version. I started
> |> |> |> |> | with 2.13, but I get the same thing with 2.14.
> |> |> |> |> |
> |> |> |> |> | Here are the key changes that I made to Makefile.win:
> |> |> |> |> |
> |> |> |> |> | RCPPINCL := -IC:/Users/pat/Documents/R/win-library/2.14/Rcpp/include
> |> |> |> |> | RCPPLIBS :=
> |> |> |> |> | C:/Users/pat/Documents/R/win-library/2.14/Rcpp/libs/i386/Rcpp.dll
> |> |> |> |> |
> |> |> |> |> | RINSIDEINCL := -IC:/Users/pat/Documents/R/win-library/2.14/RInside/include
> |> |> |> |> | RINSIDELIBS :=
> |> |> |> |> | C:/Users/pat/Documents/R/win-library/2.14/RInside/libs/i386/libRInside.dll
> |> |> |> |>
> |> |> |> |> That's not quite right, is it? What do (quoting from examples/standard/Makefile.win)
> |> |> |> |> these do:
> |> |> |> |>
> |> |> |> |> ## include headers and libraries for RInside embedding classes
> |> |> |> |> RINSIDEINCL := $(shell echo 'RInside:::CxxFlags()' | $(R_HOME)/bin/R $(R_ARCH) --vanilla --slave)
> |> |> |> |> RINSIDELIBS := $(shell echo 'RInside:::LdFlags()' | $(R_HOME)/bin/R $(R_ARCH) --vanilla --slave)
> |> |> |> |>
> |> |> |> |> | I then do:
> |> |> |> |> |
> |> |> |> |> | make -f Makefile.win
> |> |> |> |> |
> |> |> |> |> | I seem to have failed in my attempt to
> |> |> |> |> | tell it where R lives -- I get a cygwin
> |> |> |> |> | warning about MS-DOS style path, but I
> |> |> |> |> | don't think that is really a problem.
> |> |> |> |>
> |> |> |> |> R_HOME must be defined. You can get it from R, or hardcode it.
> |> |> |> |>
> |> |> |> |> The single best start is to try
> |> |> |> |>
> |> |> |> |> cd examples/standard
> |> |> |> |> make -f Makefile.win
> |> |> |> |>
> |> |> |> |> which should create 10+ executable. And you can borrow freely from that
> |> |> |> |> Makefile.win which should work.
> |> |> |> |>
> |> |> |> |> Lastly, the Cygwin thing is line noise which you can suppress by setting an
> |> |> |> |> env var appropriately. This comes from the newer Rtools.
> |> |> |> |>
> |> |> |> |> | It then attempts the g++ command, gives
> |> |> |> |> | the multiple definition statements, and:
> |> |> |> |>
> |> |> |> |> Linking is still wrong then.
> |> |> |> |>
> |> |> |> |> Dirk
> |> |> |> |>
> |> |> |> |>
> |> |> |> |
> |> |> |> | --
> |> |> |> | Patrick Burns
> |> |> |> | patrick at burns-stat.com
> |> |> |> | http://www.burns-stat.com
> |> |> |> | http://www.portfolioprobe.com/blog
> |> |> |> | twitter: @portfolioprobe
> |> |> |>
> |> |> |
> |> |> | --
> |> |> | Patrick Burns
> |> |> | patrick at burns-stat.com
> |> |> | http://www.burns-stat.com
> |> |> | http://www.portfolioprobe.com/blog
> |> |> | twitter: @portfolioprobe
> |> |>
> |> |
> |> | --
> |> | Patrick Burns
> |> | patrick at burns-stat.com
> |> | http://www.burns-stat.com
> |> | http://www.portfolioprobe.com/blog
> |> | twitter: @portfolioprobe
> |>
> |
> | --
> | Patrick Burns
> | patrick at burns-stat.com
> | http://www.burns-stat.com
> | http://www.portfolioprobe.com/blog
> | twitter: @portfolioprobe
>
--
Patrick Burns
patrick at burns-stat.com
http://www.burns-stat.com
http://www.portfolioprobe.com/blog
twitter: @portfolioprobe
More information about the Rcpp-devel
mailing list