[Rd] Win7 x64 "device not ready" error when DLLpath passed to dyn.load
Hi, Does anyone have any idea why some installations of 64 bit Windows 7 yields an error like this when passing DLLpath to dyn.load or library.dynam? > library(RGtk2) Error in inDL(x, as.logical(local), as.logical(now), ...) : unable to load shared object 'c:/R/libuser/RGtk2/libs/x64/ RGtk2.dll': LoadLibrary failure: The device is not ready. For now I guess I will fall back to setting the PATH explicitly. Michael [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Win7 x64 "device not ready" error when DLLpath passed to dyn.load
On 11-08-10 7:51 AM, Michael Lawrence wrote: Hi, Does anyone have any idea why some installations of 64 bit Windows 7 yields an error like this when passing DLLpath to dyn.load or library.dynam? library(RGtk2) Error in inDL(x, as.logical(local), as.logical(now), ...) : unable to load shared object 'c:/R/libuser/RGtk2/libs/x64/ RGtk2.dll': LoadLibrary failure: The device is not ready. For now I guess I will fall back to setting the PATH explicitly. One source of problems like that is interference from anti-virus programs. If they have exclusive access to the DLL to check it for problems, then LoadLibrary won't be able to load it. I don't know if there's a way to avoid this automatically. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build 32-bit R on x86_64?
On Tue, Aug 9, 2011 at 6:24 PM, Simon Urbanek wrote: > It actually works ;) I'm using it for testing on my RForge.net machine and > yes, it's Debian - everything just works there :). > > But back to the original question. First a minor detail, don't set > environment variables use configure variables instead. Second, don't build in > the source directory, always create an object directory. Third, r_arch is > simply a name you set for the architecture, it has no meaning other than that > it's a label. > > So now to the real stuff. If you want 32-bit build, you'll need 32-bit > runtime of everything important in your system and the multilib compilers. In > Debian (and thus likely in Ubuntu too) that can be achieved by something like > > sudo apt-get install  ia32-libs-dev lib32readline6-dev lib32ncurses5-dev > lib32icu-dev gcc-multilib gfortran-multilib > > Then you can build both 64-bit and 32-bit R, the difference will be in the > all compiler flags -- for 64-bit you'll use -m64 (or nothing since it's the > default) and for 32-bit you'll use -m32. > > So roughly something like > > tar fxz R-2.13.1.tar.gz > mkdir obj-32 > cd obj-32 > ../R-2.13.1/configure r_arch=i386 CC='gcc -std=gnu99 -m32' CXX='g++ -m32' > FC='gfortran -m32' F77='gfortran -m32' > make -j24 && sudo make install rhome=/usr/local/R/2.13 > cd .. > mkdir obj-64 > cd obj-64 > ../R-2.13.1/configure r_arch=amd64 > make -j24 && sudo make install rhome=/usr/local/R/2.13 > > That will leave you with multi-arch R that you can run with > R --arch=i386 # 32-bit > R --arch=amd64 # 64-bit > Packages will be also built as multi-libs. Good luck :) > [BTW the rhome=... setting is entirely optional, I just like to keep my R > versions organized…] > > Cheers, > Simon > Thanks Simon! Confirm that these instructions work. ia32-libs-dev was not available for Ubuntu Natty, so I installed ia32-libs instead, and the compilation works! -- Vinh __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Referencing non-CRAN extension from CRAN package
Hi r-devel, I would like to submit a package to CRAN that makes use of an Omegahat extension, RStem ( http://www.omegahat.org/Rstem/ ). What is the best way to reference it in my package, and ensure compliance with CRAN submission guidelines? Thank you for your help! Tim -- Timothy P. Jurka Department of Political Science University of California, Davis www.timjurka.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] DMTCP: checkpoint-restart for R
Hello, I hope we have the right mailing list. We are two of a team of developers for DMTCP (transparent checkpoint-restart). It runs under Linux, and is free software (LGPLv3+), found at: http://dmtcp.sourceforge.net In our latest release, version 1.2.3, we have done some simple testing on R, and find that we can successfully checkpoint and restart. Its usage can be as simple as: dmtcp_checkpoint R [ run under checkpoint control ] dmtcp_command --checkpoint [ from a diff. window, creates ckpt_R_*.dmtcp ] dmtcp_restart ckpt_R_*.dmtcp [ from original window ] ALTERNATIVELY: ./dmtcp_restart_script.sh We are interested in supporting R to a fuller extent. But we don't have enough experience with R to do more thorough testing. We have tested DMTCP on a small test in C, which frequently loads and unloads libraries (w/ dlopen). We added this test in C, because we understand that loading and unloading libraries is part of the core design of R. Would it be possible for someone to try out R/DMTCP on some realistic R programs and give us feedback on what works or doesn't work? We believe that transparent checkpointing would be helpful to the R community for any long-running programs. Thanks and best wishes, - Gene and Kapil (representing the DMTCP team) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
