similar to: R-3.0.2 - Win7_64 - alone_decoder.c: Permission denied error

Hi, I am having trouble compiling R-2.10.0 on the Solaris x86_64 platform using the native solaris-studio cc/F99 compilers. I am pretty sure that I have all my environment set up for a 64-bit compile. However, when doing a make I get the following error: /opt/solstudio12.2/bin/cc -m64 -I./api -I. -I../../../src/include -I../../../src/include -I/usr/local/include -DHAVE_CONFIG_H -KPIC -xO3 -c

I think this is more suited for the devel mailing list than the help one. I'm trying to build R on windows, With Rtools installed, and configure/make in R-3.0.2 sources folder from a cygwin console. I am stuck at the moment, because the build process tries create symlinks, and gcc build fails because the opened files containe the metadata of the not working symlink, and not the linked file.

Please note that building R on Windows is documented in "R Installation and Administration", including links to external software. Particularly there is a link to texinfo which is part of Rtools. The documentation is maintained and it is a sufficient source of information for building R on Windows. https://cran.r-project.org/doc/manuals/r-release/R-admin.html

On Thu Jan 9 2014 03:47 Henrik Bengtsson wrote: > This is is an issue that bugged me for a while. I encountered a year > ago (April 2012) when I first tried to build R from source on Windows. > I never figured out what the solution is or if I'm doing something > wrong myself (but I have found a tedious workaround). I'm still on > the same Windows 7 Ultimate machine with

Full_Name: Osiander Meixner Version: 2.9.0 (2009-04-17) OS: Windows Vista Enterprise, 32bit, SP1 Submission from: (NULL) (15.195.185.82) package XML_2.5-1 >library(XML) throws an error window saying: " RGui: RGui.exe - Unable to Locate Component This application has failed to start becuase iconv.dll was not found. Re-installing the application may fix this problem. " RGui then

I recently built R-devel on Windows XP (sessionInfo below), and when loading libraries that require the iconv.dll was getting an error stating that 'This application has failed to start because iconv.dll was not found. Re-installing the application may fix this problem.'. An R-2.8.1 that I installed using the Windows installer has this dll in R-2.8.1/bin, whereas in R-devel it is still in

Dear R developers, I am developing an R package which returns strings with new line codes. I am not sure if I should use "\r\n" or "\n" in my returned strings on Windows platforms. What is the recommended best practice for package developers (and code in base R) for coding new lines in strings? And just out of curiosity: What is the reason (or history) for preferring

This is is an issue that bugged me for a while. I encountered a year ago (April 2012) when I first tried to build R from source on Windows. I never figured out what the solution is or if I'm doing something wrong myself (but I have found a tedious workaround). I'm still on the same Windows 7 Ultimate machine with NTFS, but I now made sure I started from scratch so I have a completely

Dear list, Tadashi Kadowaki has developed a pdf device package that allows to add hyperlinks and popups to (currently) text, mtext and rect calls. The package passes R CMD check (minor warnings) and compiles on MacOS X and GNU/Linux, but we do not succeed in building the package for Windows. The current version of the package can be checked out as svn checkout

Please install from the "CRAN extras" repository (where you will find a working copy) and do NOT report a bug in R that is not a bug in R but in a contributed package / the package repository. Best, Uwe Ligges osiander.meixner at hp.com wrote: > Full_Name: Osiander Meixner > Version: 2.9.0 (2009-04-17) > OS: Windows Vista Enterprise, 32bit, SP1 > Submission from: (NULL)

On 25/07/2020 4:48 p.m., nospam at altfeld-im.de wrote: > Dear R developers, > > I am developing an R package which returns strings with new line codes. > I am not sure if I should use "\r\n" or "\n" in my returned strings on Windows platforms. > > What is the recommended best practice for package developers (and code in base R) for coding new lines in

Hello all, I'm trying to build R 32bit from source in a Windows 64 machine. I have followed the steps in "R Installation and Adiministration" ( http://cran.r-project.org/doc/manuals/R-admin.html#Getting-the-source-files) or at least I think I did everything described. I am not sure if I have installed the libjpeg, libtiff and libpng files though. I have upzipped them in the

After I installed R 2.9.0 my XML package cannot load; I get an error "This application has failed to start because iconv.dll was not found. Re-installing the application may fix this problem". I already re-installed both but the problem persists. Does anyone know what is going on? I would appreciate any help. Thanks a lot -- ___________________________ Luís Orlindo Tedeschi

Hi all -- I am working on 64-bit Windows XP. I'm not a very technical person when it comes to the command line stuff, so please forgive me if this is a stupid question. I have a bunch of HDF files, and I want to dump a single PM25 data layer from each file to .txt by invoking ncdump.exe from system(). Here's a sample command string: "C:/ncdump -v PM25 C:/01aug2010.hdf >

yes,I'm using wxruby2 When I change "samples/text/unicode.rb" 's content: require 'wx' into begin require 'wx' rescue LoadError => no_wx_err begin require 'rubygems' require 'wx' rescue LoadError raise no_wx_err end end and run unicode.rb in this way: ruby -Ku unicode.rb I got the error message like this: unicode.rb:119:

Some virtio-win drivers contain more files than just *.{cat,inf,sys}. They are filtered out currently, which prevents the drivers from being installed by PnP. Stop filtering driver files by extension, and copy all of them instead. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v1 -> v2: - update unit test to match the changed behavior v2v/v2v_unit_tests.ml | 202

Since v1: - Fix a bug in the calculation of lc_basename. By luck this doesn't affect anything given the contents of the current ISO. - Don't copy the WdfCoInstaller*.dll files. Rich.

v2 -> v3 - Don't make a special case for WdfCoInstaller* files. There is a difference of opinion about whether copying these is necessary, but it seems like it is not harmful. Rich.

Instead of trying to split and parse elements from virtio-win paths, use the '*.inf' files supplied with the drivers to control how Windows drivers are installed. The following emails best explain how this works: https://www.redhat.com/archives/libguestfs/2015-October/msg00352.html https://www.redhat.com/archives/libguestfs/2015-November/msg00065.html Currently the product variant (eg.

I am having a problem using two DLLs with the same name, but obviously located in different directories, in an R session. The troublesome package is the (Bioconductor) Rgraphviz package. It relies on (3rd party software) graphviz and imports functions from (Bioconductor) package graph. Unfortunately, the current stable release of graphviz for Windows