similar to: trouble with R CMD INSTALL for building my own library

Hi, Li and all lists, More, I have searched the web, and found one solution as described in: https://stat.ethz.ch/pipermail/bioc-devel/2007-June/001168.html But, My condition is some how different: 1) my g++ version is: g++ (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) 2) the SHLIB file is the same, but some difference in /usr/local/lib/R/etc/Makeconf: SHELL = /bin/sh SHLIB_CFLAGS =

I am running into the following issue that has been previously reported on the R-devel mailing list. The short version is that I'm writing a package for MPI, and I'd like to change CC and SHLIB_LD to "mpicc". Trying to change them in Makevars.in has no effect, because the values are clobbered by /etc/R/Makeconf. Will the following changes to Makeconf.in introduce any problems?

One way to deal with this is to install R itself with mpicc. Then all packages are installed with mpicc and get the required MPI libraries and includes by default. I have done this with R-2.13.0 on an Opteron cluster running CentOS-5 a while ago and so far it has worked out great. I crosspost to r-sig-hpc and welcome others to comment if there are potential downsides to this solution. George

Hi all, I'm trying to set up the Windows Rtools toolset for building packages with compiled code. I installed for Windows R-3.4.3 from CRAN and installed Rtools-3.4 in a custom location M:\R\R-3.4.3 and M:\R\Rtools-3.4 Following the instructions, in shell, I set Path=M:\R\Rtools-3.4\bin;M:\R\Rtools-3.4\gcc-4.6.3\bin;M:\R\R-3.4.3\bin;... (the ... are other paths irrelevant for R/Rtools).

I have been trying to compile R. I downloaded R-1.0.1.tgz(I think; the original tar file was untarred) and unpacked it with gzip. Now all the R files are in a directory named R-1.0.1. The source files (.c) are in R-1.0.1/src. There are files in R-1.0.1 named 'Makefile.in', 'Makeconf.in', and 'Makeconf'. I followed the instructions in INSTALL by typing

{message bounced because it has "$$$" in it. manually approved by list maintainer -- MM} > Date: Tue, 22 Feb 2000 13:03:35 +0100 > From: jens <jniesch at gwdg.de> > > I have trouble to install R on Sparc Sun Solaris 2.6. > make returns the error message: > Undefined symbol first referenced in file > d_lg10 ../appl/libappl.a(uncmin.o) > d_sign

Greetings, I have a computer with the following setup: 1)cblfs (pure 64-bit (amd64) linux), kernel2.6.34 gcc4.4.2 2)R-2.11.1 I compiled R with BLAS and lapack using the switched ( --with-blas="- lpthread -latlas -lfptf77blas" --with-lapack="-llapack -lcblas" ). (( http://cran.r-project.org/doc/manuals/R-admin.html#Linear-algebra) ) Prior to compiling R-2.11.1 sh

I am using the .Call interface to call c++ code from R. For that, I am trying to create a dynamic library (mylib.so) using "R CMD SHLIB" by linking my own c++ code and an external c++ library (blitz++). The makefile works fine on my Mac, produces mylib.so and I am able to call .Call() from R, but on a linux server (I think Debian), I got the following error: ---------- /usr/bin/ld:

I am using the .Call interface to call c++ code from R. For that, I am trying to create a dynamic library (mylib.so) using "R CMD SHLIB" by linking my own c++ code and an external c++ library (blitz++). The makefile works fine on my Mac, produces mylib.so and I am able to call .Call() from R, but on a linux server (I think Debian), I got the following error: ---------- /usr/bin/ld:

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).

Dear R users, we are trying to build a R package that includes a precompiled shared library, let's say mylib.so. We created the skeleton of the package and we moved the mylib.so file into the libs folder that we created at the same level of the folders man and R. Moreover we created the file NAMESPACE and we added the line useDynLib(mylib, .registration=TRUE). The building step seems to work

hi, i'm having some trouble getting a package to load a shared library object in .onLoad(...) i have a shared object file, say "mylib.so". if i start an R session, and via the CLI specify the actual library via: > dyn.load("mylib.so") everything works quite well (i.e. i can then follow with some .Call (...) methods) now, i'd like to include this shared library in

Dear helpers, I am trying to create a library which uses some Fortran source files and Lapack and Blas subroutines. The Fortran source files from the original author contain subroutines isamax.f, sgefa.f and sgesl.f, which are part of BLAS subroutines on my Linux computer, but maybe different (old) versions. So in addition to these subroutines, there are other Lapack and Blas subroutines

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

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

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

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, Standard approach to profiling dynamically loaded libraries with gprof doesn't seem to work with LLVM: export LD_PROFILE=Mylib.so export LD_PROFILE_OUTPUT=. make ENABLE_PROFILING=1 // compiling my project opt -load Profile/Mylib.so -options... but no Mylib.so.profile (or gmon.out) is produced. Profiling libc.so.6 usage by "ls -l", however, works fine. Could anyone explain

I am having trouble using Jim Lindsey's libraries because of unresolved symbols. I am currently using R 0.65.0, but had this problem in earlier releases as well. I have a RedHat 6.0 Linux on i386 and use egcs (upgraded to that distributed with rawhide, after first failures with the libraries): egcs-g77-1.1.2-19 egcs-1.1.2-19 Installation of the libraries works but on loading >

I was able to get it all to compile by altering the src_dir/etc/Makeconf file so that the shared lib LD flags variables contain -m64 SHLIB_CXXLDFLAGS = -G -m64 SHLIB_LDFLAGS = -G -m64 these only had "-G" by default. Dunno why they dont pick them up as part of the standard configure though - one for you I guess ! -- Regards,