Dear all, I have some difficulty getting R-1.3.0 to run on the alpha, with osf4.0e (Tru64, or whatever they call it... :-) ). configure reports the following configuration: R is now configured for alphaev6-dec-osf4.0e Source directory: . Installation directory: /astro/local C compiler: gcc -mieee -g -O2 C++ compiler: c++ -g -O2 FORTRAN compiler: f77 -fpe3 -g X11 support: yes Gnome support: no Tcl/Tk support: no R profiling support: yes R as a shared library: no configure: warning: you cannot build info versions of the R manuals The compilation seems to run smoothly for a while, but stops with when building ctest: Make: Cannot open ../../../../share/make/../../../../etc/Makeconf. Stop. It seems to be looking in the wrong place. I''m allready on thin ice, but I tried to set R_HOME to the source directory, which is /mn/alnair/u1/kjetikj/src/R-1.3.0/ It didn''t work, but then I edited share/make/shlib.mk to say include /mn/alnair/u1/kjetikj/src/R-1.3.0/etc/Makeconf and that seemed to work, the make was completed. I guess I might have done something entirely wrong here, though, that may be the cause of the subsequent crash. Then I do make check, and while many tests are successful, they aren''t all: creating `no-segfault.R'' running `no-segfault.R'' sh: 22380 Floating exception *** Exit 136 Stop. *** Exit 1 Stop. *** Exit 1 Stop. *** Exit 1 Stop. Help will be greatly appreciated! BTW, before I did all this, I also tried to build R using cc as C compiler with some optimization options. Last year, I had problems with cc and R, as reported in (if I remember correctly) PR#551. I figured I might give it another try, especially given the new garbage collector in 1.2.0. I failed to reproduce the problem I had back then, something that may be a good sign, to this build also didn''t pass make check. Between the builds, I cleared everything by removing source directory and re-extracting from tar. Best, Kjetil -- Kjetil Kjernsmo Graduate astronomy-student Problems worthy of attack University of Oslo, Norway Prove their worth by hitting back E-mail: kjetikj at astro.uio.no - Piet Hein Homepage <URL:http://www.astro.uio.no/~kjetikj/> Webmaster at skepsis.no -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Mon, 25 Jun 2001, Kjetil Kjernsmo wrote:> Dear all, > > I have some difficulty getting R-1.3.0 to run on the alpha, with osf4.0e > (Tru64, or whatever they call it... :-) ). > > configure reports the following configuration: > R is now configured for alphaev6-dec-osf4.0e > > Source directory: . > Installation directory: /astro/local > C compiler: gcc -mieee -g -O2 > C++ compiler: c++ -g -O2 > FORTRAN compiler: f77 -fpe3 -g > > X11 support: yes > Gnome support: no > Tcl/Tk support: no > > R profiling support: yes > R as a shared library: no >You are using GCC mixed with DEC f77? I had no compile problems with a GCC/G77 configuration: (for 1.3.0 --without-blas should be the default for tru64/alpha so could be ommitted) ./configure --enable-R-shlib --prefix=/usr/local --without-blas ... R is now configured for alphaev56-dec-osf4.0e Source directory: . Installation directory: /usr/local C compiler: gcc -mieee -I/usr/local/include C++ compiler: c++ -g -O2 FORTRAN compiler: g77 -mieee -g -O2 X11 support: yes Gnome support: no Tcl/Tk support: yes R profiling support: yes R as a shared library: yes and make check passes all tests. versions: agebhard at delta[agebhard]$ sizer -v Digital UNIX V4.0E (Rev. 1091); Sat Aug 26 15:24:28 MET DST 2000 agebhard at delta[agebhard]$ gcc -v Reading specs from /usr/local/lib/gcc-lib/alpha-dec-osf4.0/2.95.2/specs gcc version 2.95.2 19991024 (release) agebhard at delta[agebhard]$ g77 -v g77 version 2.95.2 19991024 (release) (from FSF-g77 version 0.5.25 19991024 (release)) agebhard at delta[agebhard]$ make -v GNU Make version 3.76.1, by Richard Stallman and Roland McGrath. agebhard at delta[agebhard]$ perl -v This is perl, version 5.005_02 built for alpha-dec_osf-thread Albrecht // Albrecht Gebhardt Tel.: (++43 463) 2700/3118 // Institut fuer Mathematik Fax : (++43 463) 2700/3198 // Universitaet Klagenfurt mailto:albrecht.gebhardt at uni-klu.ac.at // Universitaetsstr. 65 http://www-stat.uni-klu.ac.at/~agebhard // A-9020 Klagenfurt, Austria -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
>>>>> Kjetil Kjernsmo writes:> Dear all,> I have some difficulty getting R-1.3.0 to run on the alpha, with osf4.0e > (Tru64, or whatever they call it... :-) ).> configure reports the following configuration: > R is now configured for alphaev6-dec-osf4.0e> Source directory: . > Installation directory: /astro/local > C compiler: gcc -mieee -g -O2 > C++ compiler: c++ -g -O2 > FORTRAN compiler: f77 -fpe3 -g> X11 support: yes > Gnome support: no > Tcl/Tk support: no> R profiling support: yes > R as a shared library: no> configure: warning: you cannot build info versions of the R manuals> The compilation seems to run smoothly for a while, but stops with when > building ctest: > Make: Cannot open ../../../../share/make/../../../../etc/Makeconf. Stop. > It seems to be looking in the wrong place. I'm allready on thin ice, but I > tried to set R_HOME to the source directory, which is > /mn/alnair/u1/kjetikj/src/R-1.3.0/ It didn't work, but then I edited > share/make/shlib.mk to say > include /mn/alnair/u1/kjetikj/src/R-1.3.0/etc/Makeconf > and that seemed to work, the make was completed. I guess I might have done > something entirely wrong here, though, that may be the cause of the > subsequent crash.Why would you get ../../../../share/make/../../../../etc/Makeconf (all in one)? The ctest Makefile has top_builddir = ../../../.. R_HOME = $(top_builddir) include $(top_builddir)/share/make/shlib.mk and shlib.mk has include $(R_HOME)/etc/Makeconf ??? Which version of make is this? -k -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Just a follow-up to the part about make check failing when you build with cc and f77:> BTW, before I did all this, I also tried to build R using cc as C compiler > with some optimization options. Last year, I had problems with cc and R, > as reported in (if I remember correctly) PR#551. I figured I might give it > another try, especially given the new garbage collector in 1.2.0. I failed > to reproduce the problem I had back then, something that may be a good > sign, to this build also didn''t pass make check. Between the builds, I > cleared everything by removing source directory and re-extracting from > tar. >I''m getting the same thing. It dies in a call to the function draw.sample.cell defined in base-Ex.R, specifically at the line text(2*c, -r, string, vfont=c(typeface, fontindex), cex=1.5)>From gdb it looks like the function GVText in vfonts.c (in the src/maindirectory) is calling itself over and over until running out of memory: Program received signal SIGSEGV, Segmentation fault. 0x12012631c in Rf_GVText (x=Cannot access memory at address 0x11f7ffff8. ) at vfonts.c:86 (gdb) up #1 0x120126398 in Rf_GVText (x=6.7951783804802162, y=7.1803429085253221, unit=13, s=0x141222120 "a", typeface=0, fontindex=1, x_justify=0.5, y_justify=NaN(0x7a2), rotation=0, dd=0x1411da000) at vfonts.c:93 (gdb) up #2 0x120126398 in Rf_GVText (x=6.7951783804802162, y=7.1803429085253221, unit=13, s=0x141222120 "a", typeface=0, fontindex=1, x_justify=0.5, y_justify=NaN(0x7a2), rotation=0, dd=0x1411da000) at vfonts.c:93 ... and so on.>From vfonts.c the definition of GVText is:void GVText (double x, double y, int unit, char *s, int typeface, int fontindex, double x_justify, double y_justify, double rotation, DevDesc *dd) { if(!initialized) vfonts_Init(); if(initialized > 0) (*ptr_GVText)(x, y, unit, s, typeface, fontindex, x_justify, y_justify, rotation, dd); else error("Hershey fonts cannot be loaded"); } and (gdb) p (*ptr_GVText) $1 = {void *()} 0x120126310 <Rf_GVText> hence the infinite recursion. Can anyone tell me what was intended here for ptr_GVText? Brad -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Brad McNeney <mcneney at cs.sfu.ca> writes:> (gdb) up > #1 0x120126398 in Rf_GVText (x=6.7951783804802162, y=7.1803429085253221, > unit=13, s=0x141222120 "a", typeface=0, fontindex=1, x_justify=0.5, > y_justify=NaN(0x7a2), rotation=0, dd=0x1411da000) at vfonts.c:93 > (gdb) up > #2 0x120126398 in Rf_GVText (x=6.7951783804802162, y=7.1803429085253221, > unit=13, s=0x141222120 "a", typeface=0, fontindex=1, x_justify=0.5, > y_justify=NaN(0x7a2), rotation=0, dd=0x1411da000) at vfonts.c:93 > > ... and so on. > > From vfonts.c the definition of GVText is: > > void GVText (double x, double y, int unit, char *s, > int typeface, int fontindex, > double x_justify, double y_justify, double rotation, > DevDesc *dd) > { > if(!initialized) vfonts_Init(); > if(initialized > 0) > (*ptr_GVText)(x, y, unit, s, typeface, fontindex, > x_justify, y_justify, rotation, dd); > else > error("Hershey fonts cannot be loaded"); > } > > and > > (gdb) p (*ptr_GVText) > $1 = {void *()} 0x120126310 <Rf_GVText> > > hence the infinite recursion. Can anyone tell me what was intended here > for ptr_GVText?The GVText function from the vfonts module, cf. vfonts_Init. Looks like R_FindSymbol is malfunctioning. You might be able to catch the problem by tracing into R_FindSymbol from vfonts_Init with gdb. (Not that I''m open for helping you out with gdb the next couple of weeks. This is just an evasion from the stuff I *ought* to be doing...) -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /''_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Peter Dalgaard BSA wrote:> The GVText function from the vfonts module, cf. vfonts_Init. Looks > like R_FindSymbol is malfunctioning. You might be able to catch the > problem by tracing into R_FindSymbol from vfonts_Init with gdb.I took a quick look at this. (Anything with R_FindSymbol sparks an sense of responsibility :-)). I''m running on a Linux box so my diagnostics may not apply. However, what I see is the following: Rf_GVText is in both modules/vfonts.so and also R.bin. Depending on the behaviour of dlopen(), the call R_FindSymbol("Rf_GVText", "vfonts", NULL)) may resolve to the one in R.bin rather than the one in vfonts.so defined in g_alab_her.c. That would explain the infinite recursion. A quick look using nm gives eeyore[modules-82]>nm vfonts.so | grep GVText 0001622c T Rf_GVText eeyore[modules-83]>nm ../bin/R.bin | grep GVText 080f5794 T Rf_GVText 081858d0 b ptr_GVText illustrating the duplication and the potential for incorrect resolution by dlsym(). If this is a correct diagnosis (and I think it is), it is a further reason to use the newly introduced registration mechanism for native routines in shared libraries, both in built-in modules and also packages. I''d appreciate knowing if this is in fact the cause of the problem. Perhaps looking at the address of the Rf_GVText in R.bin and the value of ptr_GVText to see if these are the same will provide an answer. Feel free to mail me directly rather than the whole list to see if we can sort this out. D.> Brad McNeney <mcneney at cs.sfu.ca> writes: > > > (gdb) up > > #1 0x120126398 in Rf_GVText (x=6.7951783804802162, y=7.1803429085253221, > > unit=13, s=0x141222120 "a", typeface=0, fontindex=1, x_justify=0.5, > > y_justify=NaN(0x7a2), rotation=0, dd=0x1411da000) at vfonts.c:93 > > (gdb) up > > #2 0x120126398 in Rf_GVText (x=6.7951783804802162, y=7.1803429085253221, > > unit=13, s=0x141222120 "a", typeface=0, fontindex=1, x_justify=0.5, > > y_justify=NaN(0x7a2), rotation=0, dd=0x1411da000) at vfonts.c:93 > > > > ... and so on. > > > > From vfonts.c the definition of GVText is: > > > > void GVText (double x, double y, int unit, char *s, > > int typeface, int fontindex, > > double x_justify, double y_justify, double rotation, > > DevDesc *dd) > > { > > if(!initialized) vfonts_Init(); > > if(initialized > 0) > > (*ptr_GVText)(x, y, unit, s, typeface, fontindex, > > x_justify, y_justify, rotation, dd); > > else > > error("Hershey fonts cannot be loaded"); > > } > > > > and > > > > (gdb) p (*ptr_GVText) > > $1 = {void *()} 0x120126310 <Rf_GVText> > > > > hence the infinite recursion. Can anyone tell me what was intended here > > for ptr_GVText? > > The GVText function from the vfonts module, cf. vfonts_Init. Looks > like R_FindSymbol is malfunctioning. You might be able to catch the > problem by tracing into R_FindSymbol from vfonts_Init with gdb. > > (Not that I''m open for helping you out with gdb the next couple of > weeks. This is just an evasion from the stuff I *ought* to be > doing...) > > -- > O__ ---- Peter Dalgaard Blegdamsvej 3 > c/ /''_ --- Dept. of Biostatistics 2200 Cph. N > (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 > ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html > Send "info", "help", or "[un]subscribe" > (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch > _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._-- _______________________________________________________________ Duncan Temple Lang duncan at research.bell-labs.com Bell Labs, Lucent Technologies office: (908)582-3217 700 Mountain Avenue, Room 2C-259 fax: (908)582-3340 Murray Hill, NJ 07974-2070 http://cm.bell-labs.com/stat/duncan -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-help-request at stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._