[Rd] steps for problems compiling a package
Recently installed 2.12.1 on my CentOS 5.5 box. Install of R went
without incident, and packages downloaded and compiled fine. With one
exception -- my interest is somewhat in the problems with this
particular package, but more in terms of 'what to do if/when a package'
doesn't compile properly.
The offending package (in this instance) is rjags. When I try to install
it using
install.packages("rjags",lib="/usr/local/lib64/R/library")
I get the following comiplation messages:
* installing *source* package "rjags™ ...
checking for prefix by checking for jags... /usr/bin/jags
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking Console.h usability... no
checking Console.h presence... no
checking for Console.h... no
configure: error: in `/tmp/Rtmpb64Khr/R.INSTALL6524e7b4/rjags':
configure: error: "Problem with header file /usr/include/JAGS/Console.h "
See `config.log' for more details.
ERROR: configuration failed for package "rjags™
* removing ‘/usr/local/lib64/R/library/rjags™
The downloaded packages are in
˜/tmp/RtmpwAo4Qp/downloaded_packages™
Updating HTML index of packages in '.Library'
Warning message:
In install.packages("rjags", lib = "/usr/local/lib64/R/library") :
installation of package 'rjags' had non-zero exit status
So, my questions:
1. the error messages suggest looking at config.log for details. Will do
-- if someone will tell me where to find config.log?
2. in cases (such as this) where an individual package throws errors on
compilation, what is the recommended ("officially sanctified") approach
to dealing with -- post question to r-devel, or to the package maintainer?
3. in this particular instance, the problem seems to be related to a
header in /usr/include/JAGS No doubt this is because (in fact)
/usr/includes/JAGS doesn't exist. Which I suppose brings me back to
question (2).
Thanks in advance...
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] steps for problems compiling a package
1) For a source package, download it and unpack the tarball. 2) Read the instructions: you missed the README file, which starts The rjags package is an interface to the JAGS library. In order to build a binary package, or install from source, you must have a matching installation of the JAGS library. JAGS was/is already installed and functioning on the machine, so that wasn't the source of the problem. You might also be unaware of http://www-fis.iarc.fr/~martyn/software/jags/ 3) If you run R CMD INSTALL rjags then config.log will be in the rjags directory. Which is one reason to download and unpack the tarball: it will be in a temporary directory if run from install.packages() or INSTALL on the tarball. Thanks - will give that a try. Doing the direct install from CRAN led to the problems in the OP. 4) As for where to ask: see the posting guide! I did, but often there is a substantial grey area defining some overlap between various lists. Some of my 'R friends' managed to make completely different recommendations as to which list was appropriate for this (and similar) question. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] failed stats check | R 2.9.0
Trying to get R 2.90 compiled on a CentOS 5.3 (i.e., RHEL 5.3) box, 64-bit. Machine has Opteron chips, so downloaded and installed ACML 4.3.0. Configured R with ./configure --with-lapack="-L/usr/lib64" --with-blas="-L/opt/acml4.2.0/gfortran64/lib -lacml" --with-tcltk Absolutely no problems/errors. Recommended packages there - blas and lapack both there. Ran make. Again, no problems/errors that I could find. Problems with make check, though. base -> no problems tools -> no problems Devices -> no problems graphics -> no problems stats -> failed (!) Here is what I get - suggestions/pointers to the obvious most appreciated. Error: testing 'stats' failed Execution halted make[3]: *** [test-Examples-Base] Error 1 make[3]: Leaving directory `/root/Desktop/R-2.9.0/tests/Examples' make[2]: *** [test-Examples] Error 2 make[2]: Leaving directory `/root/Desktop/R-2.9.0/tests' make[1]: *** [test-all-basics] Error 1 make[1]: Leaving directory `/root/Desktop/R-2.9.0/tests' make: *** [check] Error 2 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] more on make check states failure
Ran make check-devel and make check-all (for more comprehensive testing) - same error messages - not even sure where to look in tests or Examples for 'help' - no logs, or files with .fail extension or anything I might *guess* to look for. I've never had this problem before - the only thing different on the box from when I had 2.9.0 running fine is 1. change from Fedora Core 8 -> CentOS 5.3 2. ACML updated from 4.2.0 -> 4.3.0 Thats it! Unless AMCL 4.3.0 is doing something 'weird', I'm stumped. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] can't use ATLAS or ACML | 2.9.0
Brian - Cheers - followups below. Prof Brian Ripley wrote: On Fri, 26 Jun 2009, Evan Cooch wrote: So, tried again from scratch. Again, CentOS 5.3, which is essentially RHEL 5.3. ./configure --with-blas="-L/opt/acml4.3.0/gfortran64/lib -lacml" In config.log, get things like configure:37199: checking for dgemm_ in -L/opt/acml4.3.0/gfortran64/lib -lacml configure:37230: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib64 conftest.c -L/opt/acml4.3.0/gfortran64/lib -lacml -$ conftest.c: In function 'main': conftest.c:189: warning: implicit declaration of function 'dgemm_' /usr/bin/ld: warning: libgfortran.so.3, needed by /opt/acml4.3.0/gfortran64/lib/libacml.so, not found (try using -rpath or -rpath-link) So you don't have a compatible libgfortran installed (not surprising as your OS is rather old): try a version of ACML of comparable age to your OS that uses. (I seem to remember needed ACML 4.1.0 on Fedora 8.) Thanks - but I'm not sure I would classify CentOS as 'old' - it is RHEL 5.3 (basically built straight from open-sourced RHEL code), and RHEL 5.3 is the current release of the 'flagship' OS from Redhat. I grant you it *is* old by (say) Fedora standards, which has a release schedule measured in months (whereas RHEL is measured in 1-2 years), but I was aiming for stability. We also needed to add /opt/acml4.3.0/gfortran64/lib to the ldconfig files (something AMD should organize). Try ./configure --with-blas="-L/usr/lib64/atlas -lf77blas -latlas" I get the following configure:37199: checking for dgemm_ in -L/usr/lib64/atlas -lf77blas -latlas configure:37230: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib64 conftest.c -L/usr/lib64/atlas -lf77blas -latlas -lg$ conftest.c: In function 'main': conftest.c:189: warning: implicit declaration of function 'dgemm_' /usr/bin/ld: cannot find -lf77blas collect2: ld returned 1 exit status configure:37236: $? = 1 configure: failed program was: What puzzles me is that lf77blas is definitely in /usr/lib64/atlas - but configure couldn't find (?). Perhaps its because 100% of the libs in the atlast subdir are xxx.so.3 (perhaps R config is looking for so.1 libs?). It is looking for .so or .a (a Linux linker always does). Where did you get ATLAS from? This is what happens if you install the foo and not the foo-devel RPM for some package. And indeed, on Fedora 10 you need the atlas-devel RPM Ah - that rings a bell (can you tell I was doing this late into the wee hours?). Atlas was distributed as an RPM (or, rather, downloaded via the CentOS standard yum repo). Everything in /usr/lib64/atlas is an .so.3 file - nothing with .so or .a as suffix. I suspect that many/most of the problems I'm having with getting R to compile (with BLAS and LAPACK) are related to these basic issues - if I can't do even a simple compile with blas, then whats left? Ask for local help on your OS! You seem to be asking many questions about your OS here, and be assured that R works with ATLAS and ACML flawlessly in well-sorted OS installations. Things like the need for the foo-devel RPM are in the R installation manual which the INSTALL file asked you to study (before posting). Well, I've actually gone through the manual you refer to - missed the bit on foo-devel (which applies only to atlas, it would seem) - my oversight - mea culpa. However, the documentation doesn't (and isn't expected) to elaborate on what you refer to as a 'well-sorted' OS. In other words, I had no a priori expectation of a problem - since CneenOS is RHEL, and RHEL has a rather large market share. I would have assumed (naively, in hindsight) that the combination of CentOS and ACML 4.3.x would have been 'well sorted'. (as an aside - some of my friends at Sun tell me 'standard Linux' for file structures, libs and such is an oxymoron ;-) It would appear not - at least in this instance. On the other hand, CentOS picked up all of my twitchy harddare (RAID cards, special NICs) without missing a beat, networked without so much as a single tweak being needed, and has performed flawlessly for everything...except getting R compiled with ACML support. Note that a much simpler way (as recommended the manual!) to add an optimized BLAS is to switch the libRblas. E.g. I have a note in my build file gannet% cat I.USED ## later ## mv lib/libRblas.so lib/libRblas.so.keep ## ln -s /opt/acml4.3.0/gfortran64_mp/lib/libacml_mp.so lib/libRblas.so And most users of R do so little linear algebra that an optimized BLAS make a negligible difference in performance (but often an appreciable one to accuracy). Agreed on the latter point (generally), but I do a fair bit of stuff with big matrices, and wanted both accuracy *and* speed. Wrt to the first point, I tried that in fact (but didn't report - in fact, I tried about 15-20 different combinations of various approaches). When I try that - using *exact
[Rd] symbolic linking to library files
I handle SysAdmin for a multi-user Linux box, with R 2.7.1 compiled and installed to make usee of ACML (Opteron chips). The library files (packages) are installed to /usr/local/lib64/R/library Everything works as it should, except for the following. Say I have a user (an R developer) who has developed a package called Blaster. We'll call the user guru. Now, /home/guru/Blaster, contains the needed directory structure to do a normal install (i.e., R CMD INSTALL Blaster), but the user can't write to /usr/local/lib64/R/library. Sure, said user can do a local install, so *he* can use Blaster, but we'd like it so that changes guru makes to Blaster are available to everyone. My first simple-minded solution to this was to simply create a symbolic link to Blaster from within /usr/local/lib64/R/library. However, this doesn't seem to work. Invoking library(Blaster) gives an error message about Blaster not being a valid library. Apparently, R CMD INSTALL Blaster does something more than simply copy Blaster to the appropriate directory. I did a quick perusual of what I could find online, but I suspect I've missed something - hopefully not too embarassingly obvious. Basically, what I'd like to do is create a symbolic link to 'something' that guru creates, from within /usr/local/lib64/R/library, such that (i) Blaster is available to all users on the system, and (ii) any changes Guru makes to his code are automatically available. Is anything like this feasible? [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] symbolic linking libs | thanks!
Several good suggestions were sent my way - much appreciated. In my experience, any solution to a problem that gives a user write access to anything other than their own /home directories is a disaster waiting to happen (spoken as someone who has burned in past doing otherwise). So, I'll pursue some approaches that don't reequire the /lib access option. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] properly reporting compile bugs
A while ago I decided to simply download and install every package on CRAN (disk space is cheap these days...). In the process, I kept loose track of which packages generated one or more 'compilation errors' during the install process (machine runs 64-bit Fedora 8, gcc 4.1 etc. etc). Most of the errors seemed to occur in packages I have little need for at present, but as a courtesy, I thought it might be helpful to report these 'errors' - but, how, and to whom (package maintainer)? Is there a preferred (official) mechanism for this? A pointer to the relevant webpage would be more than sufficient. Some of the errors or lib dependencies, which are perhaps not generally useful to report. But some are outright code errors - either syntax problems, or deprecated bits of C and Fortran. Thanks in advance... [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problems installing rjags | tcltk
Greetings. Running Fedora Cora 8 on multi-Opteron system - full 32- and 64-bit libs installed (R compiled 64-bit on this machine). R 2.9.0 - libs sitting in /usr/local/lib64/R/library. Trying to install JAGS, with rjags. Partial success. For JAGS install: |./configure --with-jags-modules=/usr/local/lib/JAGS/modules --libdir=/usr/local/lib64 make make check make install Seems to work / no config or make errors, and jags fires up fine when I invoke it. Problems start with rjags. Download latest tarball, and try || R --with-jags-modules=/usr/local/lib/JAGS/modules/ CMD INSTALL rjags_1.0.3-8.tar.gz ||Here is the relevant part of the error messages I get: ** Preparing for lazy loading Loading required package: lattice Error: package 'tcltk' does not have a name space ERROR: lazy loading failing for package 'rjags' |* Removing '/usr/local/lib64/R/library/rjags' No idea what to do now. Only tcltk-like package I see is tcltk2. Tried installing it, get the following error: Error in library(pkg, character.only=TRUE, logical.return=TRUE, lib.loc-lib.loc) : 'tcltk' is not a valid installed package. ERROR: lazy loading failed for package 'tcltk2' So, I'm stumped. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [Fwd: problems installing rjags | tcltk]
Quick followup. Confirmed that TCl/Tk are both installed on the machine (they are, in both 32- and 64-bit flavours), as are all tcl and tk-related libs, devel packages, and about everything else I could find. It occurred to me that perhaps the R I compiled isn't 'tcltk' aware. I checked the config.log, and there is some hint that this might be the case. Just before ## File substitutions ## I see use_tcltk='no' Further upstream in the config.log, I see configure:42914: checking for tcl.h conftest.c:204:17: error: tcl.h: No such file or directory and ac_cv_env_TCLTK_CPPFLAGS_set= ac_cv_env_TCLTK_CPPFLAGS_value= ac_cv_env_TCLTK_LIBS_set= ac_cv_env_TCLTK_LIBS_value= and r_cv_header_tcl_h=no and TCLTK_CPPFLAGS='' TCLTK_LIBS='' TCL_CONFIG='' So, it seems as if my self-rolled R isn't TCLTK 'aware'. Is simply adding --with-tcltk to my configure call (i.e., ./configure --with-lapack="-L/usr/lib64" --with-blas="-L/opt/acml4.2.0/gfortran64/lib -lacml" --with-tcltk the solution? I figure worth asking before I literally 'start over'. I see from the manual for linux installs there may be some issues with playing nice if both 32- and 64-bit versions of Tcl/Tk are installed. Original Message Subject:[Rd] problems installing rjags | tcltk Date: Thu, 30 Apr 2009 11:26:43 -0400 From: egc To: r-devel@r-project.org Greetings. Running Fedora Cora 8 on multi-Opteron system - full 32- and 64-bit libs installed (R compiled 64-bit on this machine). R 2.9.0 - libs sitting in /usr/local/lib64/R/library. Trying to install JAGS, with rjags. Partial success. For JAGS install: |./configure --with-jags-modules=/usr/local/lib/JAGS/modules --libdir=/usr/local/lib64 make make check make install Seems to work / no config or make errors, and jags fires up fine when I invoke it. Problems start with rjags. Download latest tarball, and try || R --with-jags-modules=/usr/local/lib/JAGS/modules/ CMD INSTALL rjags_1.0.3-8.tar.gz ||Here is the relevant part of the error messages I get: ** Preparing for lazy loading Loading required package: lattice Error: package 'tcltk' does not have a name space ERROR: lazy loading failing for package 'rjags' |* Removing '/usr/local/lib64/R/library/rjags' No idea what to do now. Only tcltk-like package I see is tcltk2. Tried installing it, get the following error: Error in library(pkg, character.only=TRUE, logical.return=TRUE, lib.loc-lib.loc) : 'tcltk' is not a valid installed package. ERROR: lazy loading failed for package 'tcltk2' So, I'm stumped. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Fwd: problems installing rjags | tcltk]
That was it - rebuilt R with --with-tcltk, then tried rebuilding rjags. Seems to have done the trick. egc wrote: Quick followup. Confirmed that TCl/Tk are both installed on the machine (they are, in both 32- and 64-bit flavours), as are all tcl and tk-related libs, devel packages, and about everything else I could find. It occurred to me that perhaps the R I compiled isn't 'tcltk' aware. I checked the config.log, and there is some hint that this might be the case. Just before ## File substitutions ## I see use_tcltk='no' Further upstream in the config.log, I see configure:42914: checking for tcl.h conftest.c:204:17: error: tcl.h: No such file or directory and ac_cv_env_TCLTK_CPPFLAGS_set= ac_cv_env_TCLTK_CPPFLAGS_value= ac_cv_env_TCLTK_LIBS_set= ac_cv_env_TCLTK_LIBS_value= and r_cv_header_tcl_h=no and TCLTK_CPPFLAGS='' TCLTK_LIBS='' TCL_CONFIG='' So, it seems as if my self-rolled R isn't TCLTK 'aware'. Is simply adding --with-tcltk to my configure call (i.e., ./configure --with-lapack="-L/usr/lib64" --with-blas="-L/opt/acml4.2.0/gfortran64/lib -lacml" --with-tcltk the solution? I figure worth asking before I literally 'start over'. I see from the manual for linux installs there may be some issues with playing nice if both 32- and 64-bit versions of Tcl/Tk are installed. Original Message Subject: [Rd] problems installing rjags | tcltk Date: Thu, 30 Apr 2009 11:26:43 -0400 From: egc To: r-devel@r-project.org Greetings. Running Fedora Cora 8 on multi-Opteron system - full 32- and 64-bit libs installed (R compiled 64-bit on this machine). R 2.9.0 - libs sitting in /usr/local/lib64/R/library. Trying to install JAGS, with rjags. Partial success. For JAGS install: |./configure --with-jags-modules=/usr/local/lib/JAGS/modules --libdir=/usr/local/lib64 make make check make install Seems to work / no config or make errors, and jags fires up fine when I invoke it. Problems start with rjags. Download latest tarball, and try || R --with-jags-modules=/usr/local/lib/JAGS/modules/ CMD INSTALL rjags_1.0.3-8.tar.gz ||Here is the relevant part of the error messages I get: ** Preparing for lazy loading Loading required package: lattice Error: package 'tcltk' does not have a name space ERROR: lazy loading failing for package 'rjags' |* Removing '/usr/local/lib64/R/library/rjags' No idea what to do now. Only tcltk-like package I see is tcltk2. Tried installing it, get the following error: Error in library(pkg, character.only=TRUE, logical.return=TRUE, lib.loc-lib.loc) : 'tcltk' is not a valid installed package. ERROR: lazy loading failed for package 'tcltk2' So, I'm stumped. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
