"R Installation and Administration", section 2.5 "Sub-architectures" describes
calling specific builds of R using the call "R --arch=name". I am trying to
build and install three versions of R-2.9.1, each configured with a different
valgrind-instrumentation level ("Writing R Extensions", section 4.
You're confusing rhome and arch - the above makes no sense. Let rhome
alone and you should be fine. (And make sure you're not building in
the source tree - you should be using something like mkdir obj_vg0 &&
cd obj_vg0 && ../R-2.9.1/configure ...)
Thanks Simon. I'd already tried various var
is suspect installing to seperate _vg0, _vg1 and _vg2 directories
could be the problem. I'll retry and post the results.
Well, the following script didn't work
cd /usr/local/lib
sudo mkdir R
cd /usr/local/lib/R
sudo /usr/local/src/R-2.9.2/configure --enable-memory-profiling
--with-valgrind-inst
^^-- this is really bad form - you should never build/compile
software as root. The location of the build directory is irrelevant
so use /tmp or you home or something like that ... (usualy the
fastest disk ;))
OK, thanks for the tip, although I don't understand the configure - make -
insta
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 1
I am running Ubuntu jaunty on a laptop. Any ideas as to what I might need to
configure next?
thanks
David
--
David Pleydell
UMR BGPI
CIRAD
TA A-54/K
Campus International de Ba
ght need to
configure next?
thanks
David
--
David Pleydell
UMR BGPI
CIRAD
TA A-54/K
Campus International de Baillarguet
34398 MONTPELLIER CEDEX 5
FRANCE
Tel: +33 4 99 62 48 65 - Secrétariat : +33 4 99 62 48 21
Fax : +33 4 99 62 48 22
http://umr-bgpi.cirad.fr/trombinoscope/pleydell_d.htm
https:
not really answering your question, but I find it more useful to
R -d gdb
or
R -d gdb -f test.R
where test.R reproduces the bug in some minimal code. A variant is
R -d valgrind -f test.R
if the memory problem is not easy to spot.
Thanks for your reply Martin
Yes, I have used that route
To answer my own question.
My mistake was that "ulimit -c unlimited" applies to the current bash session
only. I had used this call in a bash *shell* buffer in emacs but this was
unable to affect R processes started in emacs with C-u M-x R, hence no core
files. Running the buggy code from R start
usually what happens is (# meant to be a comment char)
% R -d gdb -f test.R
gdb> run
...segfault happens, breaks into gdb
gdb> bt # print the backtrace
gdb> up # move up the stack, to get to 'your' frame
gdb> l # show source listing, use -O0 compiler flag, see gdb> help dir
gdb> print some
nd the expected next
line). So to me it looks like there is still a gdb ~ optimisation conflict.
Does this mean I have to have a copy of R compiled from source using the -O0
flag too?
thanks
David
--
David Pleydell
UMR BGPI
CIRAD
TA A-54/K
Campus International de Baillarguet
34398 MONTPELLIE
Looking through the archives I found this thread
http://tolstoy.newcastle.edu.au/R/e4/devel/08/02/0347.html
and so I tried
MAKEFLAGS="CFLAGS=-g -O" R CMD SHLIB ...
and this worked great.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mail
Lets say I have two source files file1.c and file2.c
The latter just contains sub-routines to be used by the first. i.e. in file1.c I
have the line
#include "file2.c"
Let's say "R CMD SHLIB file1.c" runs perfectly and I want to include the code in
a package, "R CMD build" also runs fine but R
Create a file named Makevars in the same directory and put the
following line in it:
OBJECTS=file1.o
Then R CMD SHLIB will only compile file1.c.
Kjell
Great, that's done the job nicely.
Many thanks
David
__
R-devel@r-project.org mailing list
htt
I understand global variables can be a bad idea, but even so I would like to
understand what is going on here...
### DESCRIPTION OF PROGRAM ###
...I have a strange bug on a global variable in some C code which I am compiling
using
$ MAKEFLAGS="CFLAGS=-g -O0" R CMD SHLIB myProgram.c
the global v
To answer my own question...
I have two copies of my program
1) a working copy stored in $PROJECT/analysis/c
2) a packaged copy stored in $PROJECT/analysis/myPackage_1.0.2.tar.gz
I have been running a script which does the following
library(myPackage)
load(myData)
detach("package:myPackge")
dy
usually what happens is (# meant to be a comment char)
% R -d gdb -f test.R
gdb> run
...segfault happens, breaks into gdb
gdb> bt # print the backtrace
gdb> up # move up the stack, to get to 'your' frame
gdb> l # show source listing, use -O0 compiler flag, see gdb> help dir
gdb> print some
... If I launch gdb this way I don't have any means to navigate through
previously executed gdb lines using M-p and M-n, but following a
(gdb) run
or
(gdb) continue
I can use M-p and M-n to recall previous R commands
If I launch gdb in other ways M-p and M-n function as expected. I
suppose there
iles and in Makevars they
have "PKG_CFLAGS = -I./gsl". I have copied this approach, but wonder if using
the standard
"R CMD build myPackage"
"R CMD check myPackage"
needs modifying in some way?
All hints or ideas welcome.
Thanks
David
--
David Pleydell
UMR BG
You'll need something like :
PKG_LIBS=-lgsl -lgslcblas
in your Makevars.
This is from package gsl (on CRAN).
Of course! That makes sense 'cause I was already compiling using
MAKEFLAGS="CFLAGS=-g -O0" R CMD SHLIB sharka.c -lgsl -lgslcblas
and including the above line in Makevars has done the
19 matches
Mail list logo