On 31 Oct 2006 12:05:21 +0100, Peter Dalgaard <[EMAIL PROTECTED]> wrote: > > [move to r-devel, put maintainer in loop] > > Patrick Connolly <[EMAIL PROTECTED]> writes: > > > On Mon, 30-Oct-2006 at 04:44PM -0500, Duncan Murdoch wrote: > > > > > > |> Try "R CMD printenv R_HOME" and you'll find which R home directory it is > > |> using. You can see a lot more with "R CMD printenv" or various options > > |> to "R CMD config". > > > > Thanks for that information. It knocks my theory on the head. Pity > > that, because I might have been able to do something about it if that > > was the problem. Now I'm at a loss to work out why lme4 installation > > cannot find Matrix, and more strangely, why nothing else gave a > > similar problem. I think I've tried every version of lme4 and Matrix > > that has emerged since R-2.4.0 has been released. > > > > The fact that no other Red hat user has a problem indicates the > > problem is this end; but I'm short of ideas about where to look. > > Looks like it's back to versions 6 months old -- like proprietary > > software users have to put up with. :-( > > Hmmm, I can provoke this on SUSE too (I was going to ask you to try > this!): > > mkdir foo > MY_R=~/misc/r-release-branch/BUILD/bin/R > R_LIBS=foo $MY_R --vanilla << EOF > options(repos=c(CRAN="http://cran.dk.r-project.org";)) > install.packages("lme4", depend=TRUE) > EOF > > This installs Matrix alright, then dies with > > Warning in install.packages("lme4", depend = TRUE) : > argument 'lib' is missing: using foo > trying URL 'http://cran.dk.r-project.org/src/contrib/lme4_0.9975-8.tar.gz' > Content type 'application/x-tar' length 235617 bytes > opened URL > ================================================== > downloaded 230Kb > > * Installing *source* package 'lme4' ... > ** libs > > gcc -I/usr/local/src/pd/r-release-branch/BUILD/include > -I/usr/local/src/pd/r-release-branch/BUILD/include > -I/usr/local/include -fpic -g -O2 -std=gnu99 -c Wishart.c -o Wishart.o > > In file included from Wishart.h:4, > from Wishart.c:1: > lme4_utils.h:9:20: Matrix.h: No such file or directory > In file included from Wishart.h:4, > from Wishart.c:1: > lme4_utils.h:25: error: syntax error before "c" > lme4_utils.h:25: warning: type defaults to `int' in declaration of `c' > lme4_utils.h:25: warning: data definition has no type or storage class > lme4_utils.h:163: error: syntax error before "cholmod_factor" > lme4_utils.h:177: error: syntax error before "cholmod_factor" > make: *** [Wishart.o] Error 1 > ERROR: compilation failed for package 'lme4' > > And Matrix.h is sitting happily in foo/Matrix/include/ but obviously > not getting included. Should there have been a copy inside lme4?
Not according to my understanding of how the "LinkingTo:" specification in the DESCRIPTION file is to work. The headers for the C functions exported by the Matrix package are defined Matrix/inst/include so they can be changed in one place if the API changes. The "LinkingTo:" specification is designed to put these headers on the -I path at the time of compilation of the lme4 package source code. For some reason it didn't do that in this case. > What is not obvious to me is how this can work anywhere... > > I also tried unpacking the lme4 directory from its tarball, dropping > all files from the Matrix installed include dir into lme4/src and then > > $MY_R CMD INSTALL -l foo lme4 > > but no go > > gcc -shared -L/usr/local/lib64 -o lme4.so Matrix_stubs.o Wishart.o > glmer.o init.o lme4_utils.o lmer.o local_stubs.o pedigree.o > -L/usr/local/src/pd/r-release-branch/BUILD/lib -lRlapack > -L/usr/local/src/pd/r-release-branch/BUILD/lib -lRblas -lg2c -lm > -lgcc_s > > local_stubs.o(.text+0x0): In function `M_numeric_as_chm_dense': > /home/bs/pd/tmp/lme4/src/Matrix_stubs.c:420: multiple definition of > `M_numeric_as_chm_dense' > Matrix_stubs.o(.text+0x0):/home/bs/pd/tmp/lme4/src/Matrix_stubs.c:420: first > defined here You don't want to compile both Matrix_stubs.c and local_stubs.c. All that local_stubs.c does is include Matrix_stubs.c, the reason being that those wrapper functions are needed locally but it is much cleaner if they are defined in only one place. The file Matrix_stubs.c is never compiled by itself. It is just there to provide the definitions of the functions. Check Luke's documentation and examples for using R_RegisterCCallable and R_GetCCallable. > local_stubs.o(.text+0x70): In function `M_dpoMatrix_chol': > /home/bs/pd/tmp/lme4/src/Matrix_stubs.c:412: multiple definition of > `M_dpoMatrix_chol' > Matrix_stubs.o(.text+0x70):/home/bs/pd/tmp/lme4/src/Matrix_stubs.c:412: first > defined here > ..etc.. > > -- > O__ ---- Peter Dalgaard Øster Farimagsgade 5, Entr.B > c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K > (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 > ~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 > > ______________________________________________ > 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
