similar to: Setting the path to Rtools for package compilation on Windows

I can confirm the behaviour that you report.? Usually I put Rtools in c:\programs\Rtools and modify the path accordingly. Recently (don't recall for how long) I have encountered the same problems as you have and I have resorted to moving Rtools to c:\Rtools I have no idea as how to proceed; perhaps it could be worth trying an older version of Rtools (though that may cause other problems).

Hi all, a user contacted me about a segfault when installing WGCNA package dowloaded from CRAN. I also see a segfault like that on certain installs of R. The package passes all CRAN checks, so presumably this has something to do with the R installation or environment. The R versions here are not the newest but I would guess that this is not an R version issue. I'm attaching two

Hi Avraham, What a coincidence, I have been following this post of yours: https://www.avrahamadler.com/2013/10/24/an-openblas-based-rblas-for-windows-64-step-by-step/ Looks like this post is slightly older than what you have shared previously. It is strange that you did not get the attachments. I am pasting the contents of the MkRules.local here:

Hi All, I am trying to compile R from source on a 64 bit Windows. I have downloaded and installed all the third party software as per the R - documentation. The compilation starts fine and after a while it stops with the following error message: D:/Rtools/mingw_64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lRgraphapp collect2.exe: error: ld

Hello fellow R users, I am currently learning to use R, so please forgive me if there is an obvious explanation for the following problem. My goal is to perform WGCNA on a dataset of 19776 genes, so I opted to follow the block-wise network construction (Section 2c) in the WGCNA R Tutorial by Peter Langfelder and Steve Horvath. I ended up with 10 blocks and am able to plot the dendrograms and

I encountered this issue a couple of months ago and resolved it by installing Rtools in the default directory C:\Rtools, see below for details. I didn't have time to prepare a proper error report and in fact suspected that I may be messing up something. I tracked down the error by installing from the command line, rather than with install.packages(). On Windows I keep multiple versions of

Hi, I'm running a tutorial ("Meta-analyses of data from two (or more) microarray data sets"), which use wgcna package. I have an error in the function modulePreservation (it is below). I'm using R2.13 Can you help me? Do you know, what is happens? Thanks Raquel multiExpr = list(A = list(data=t(badea)),B = list(data=t(mayo))) # two independent datasets (dim = 13447 x 36) mp =

On Tue, Feb 13, 2018 at 2:20 AM, Jeroen Ooms <jeroenooms at gmail.com> wrote: > Thanks for your question. Your logs show that 'gcc' is not found. As > of R 3.3 you need to set the path to the compiler using the BINPREF > variable. This is because we ship two separate versions of gcc, one > targeting win32 and one targeting win64. I am not sure what your > rtools

Hi all, I am having some problems in updating some packages from source. I start with : install.packages("Boom",lib="C:/RownLib",type="source") I get the following error message : * installing *source* package 'Boom' ... ** package 'Boom' successfully unpacked and MD5 sums checked ** libs *** arch - i386 c:/Rtools/mingw_32/bin/g++ -std=gnu++11

Good evening. Testing the most recent version of Rtools, the build stops about when text.c is being compiled in the tools package (just after R.Lapack). The compilation is looking for gcc in C:, even though RTOOLS is set for another drive, and the compilation has successfully run until this point. This did not happen last night with version 1955. I've uninstalled and reinstalled Rtools three

Hi, As far as I can see, no. On checking, I have confirmed that the only location of cygwin1.dll is : C:\Rtools\bin Thanks Vivek 2017-06-03 12:57 GMT+02:00 Duncan Murdoch <murdoch.duncan at gmail.com>: > On 03/06/2017 6:31 AM, Vivek Sutradhara wrote: > >> Hi all, >> I am having some problems in updating some packages from source. I start >> with : >>

Hi all, I maintain the WGCNA package which at present has nearly 200 functions. In the future there will be more. Curious whether it would be preferable or useful to split the package into a couple different ones with different aims. Obviously, when one calls a function in R, package name spaces have to be traversed to find the matching name - does the speed of this depend on how functions are

On 03/06/2017 6:31 AM, Vivek Sutradhara wrote: > Hi all, > I am having some problems in updating some packages from source. I start > with : > install.packages("Boom",lib="C:/RownLib",type="source") > > I get the following error message : Do you have multiple copies of cygwin1.dll? Duncan Murdoch > > * installing *source* package

On 03/06/2017 7:00 AM, Vivek Sutradhara wrote: > Hi, > As far as I can see, no. > > On checking, I have confirmed that the only location of > cygwin1.dll is : > C:\Rtools\bin I would re-install Rtools, and make sure C:\Rtools\bin appears first in your PATH. Duncan Murdoch > > Thanks > Vivek > > 2017-06-03 12:57 GMT+02:00 Duncan Murdoch <murdoch.duncan at

----- Original Message ----- > From: "Duncan Murdoch" <murdoch.duncan at gmail.com> > To: "Hsiu-Khuern Tang" <tangoh at gmail.com>, r-devel at r-project.org > Sent: Monday, March 9, 2015 10:40:02 AM > Subject: Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib) > > On 09/03/2015 11:07 AM, Hsiu-Khuern Tang wrote: > > On

----- Original Message ----- > From: "Duncan Murdoch" <murdoch.duncan at gmail.com> > To: "Dan Tenenbaum" <dtenenba at fredhutch.org> > Cc: "Hsiu-Khuern Tang" <tangoh at gmail.com>, r-devel at r-project.org > Sent: Tuesday, March 10, 2015 11:37:12 AM > Subject: Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

On 10/03/2015 3:17 PM, Duncan Murdoch wrote: > On 10/03/2015 2:56 PM, Dan Tenenbaum wrote: > > > > > > ----- Original Message ----- > >> From: "Duncan Murdoch" <murdoch.duncan at gmail.com> > >> To: "Dan Tenenbaum" <dtenenba at fredhutch.org> > >> Cc: "Hsiu-Khuern Tang" <tangoh at gmail.com>, r-devel at

It seems like many of the multi-threaded BLASes have some sort of fundamental problem preventing use in the way Juan suggests: - Dirk's vignette states that ATLAS "fixes the number of cores used at compile-time and cannot vary this setting at run-time", so any user-friendly implementation for R would have to compile ATLAS for 1-16 threads to allow the user to switch at run-time.

First, please read WGCNA FAQ at https://labs.genetics.ucla.edu/horvath/CoexpressionNetwork/Rpackages/WGCNA/faq.html regarding using RNA-seq and other count data. Second, if you insist on using WGCNA on raw count data (which I don't recommend), use something like storage.mode(datExpr) = "double" and try again. Peter On Sun, Jul 9, 2017 at 2:29 AM, Ankush Sharma <ankush.sak at

Oops, I think both of us forget to cite the r-devel channel. Best, Jiefei On Tue, Mar 10, 2020 at 5:13 AM Wang Jiefei <szwjf08 at gmail.com> wrote: > Thanks for your quick response, Tomas. > > Yes, this is a path issue, I think the problem is related to R, not the > Rtools make. I built an example package for reproducing the problem: > https://github.com/Jiefei-Wang/example