[R-sig-Debian] Aborted (core dumped) installing packages

[Paul Johnson]

On Sat, Mar 9, 2013 at 9:03 PM, Carlos Solís
>>>
>>>   1 GB of RAM
>>> Intel® Atom™ CPU N455 @ 1.66GHz × 2
>>> Linux Kernel 3.5.0-25-generic
>>>
>>>
>>>     Thanks for the response!!!
>
Hi, I'm a latecomer to this thread. I don't have the answer, but I
have some other questions. This may help you to think through the
trouble you are seeing. I think the solution is more likely to be
something simple than something esoteric.

First, is the faraway package the only one with trouble? Can you
install and run examples for any of the more complicated ones, such as
lme4 or car?

Second, when you install deb package updatess, you need to make sure
all your existing R packages are compatible with the R you have now.
The binaries from R-2.15.2 packages don't cooperate.

updatePackages(checkBuild=TRUE)

will replace the ones you built on R-2.15.2. There may be a little
trouble because several versions of packages may exist, say under
/usr/lib/R and /usr/local/lib/R/site-library and ~/HOME/R.  If you
have some packages for R that are from the Ubuntu server, you may need
to double check about them. Or re-install or remove them with the deb
package manager.

Incidentally, I don't think you need to "sudo" install. Of course, if
you did before, you probably should be root and go erase the faraway
folder that got installed under /usr/local.   If run install.packages
as an ordinary user, it will install in your home directory, under
~/R. The R function .libPaths() should have that home directory as the
first spot.  No root required.

Third, when installing packages in R, there is a danger because R does
not install pre-requisites automatically.  Thus, it is best to
remember the depends= option, such as

install.packages("faraway", dep = TRUE)

which will take in suggested and required packages.  But you can be
more conservative

install.packages("faraway", dep = c("Depends"))

Supposing you figure that out, then you have to consider the
possibility that you have some binary incompatibilities between your
CPU and the packages offered by the central server.  "Atom" makes me
curious, I don't have any of them. I wonder if there might be some
binaries that are not truly compatible with your processor.

I'm running Debian wheezy pre-release and there are some libraries
that are not compatible with the R that's available in deb packages.
So I build packages for myself.  And you could try that too. The apt
system has a command to download the source code and the packaging
material.  Usually, that's as simple as

$ mkdir r-base
$ cd r-base
$ sudo apt-get source r-base

Then cd into the build directory and type

$ dpkg-buildroot -rfakeroot

Of course,this won't work unless you have the devel packages required.
 There's an apt command "build-requires" that can get them for you,
but I don't have the full syntax. But if you decide to try, do that
first.

I've just tried it on my system right now, to paste in some "I told
you so" output, but my system says my version of libcairo2 does not
match what is expected in the source code for the package, so I have a
hairy problem to work out. But your system may not be as
version-confused as mine, because I'm on the bleeding edge of some
pieces.

Good luck, let us know how it goes for the steps I describe above.
I've been using R a long time, and I'm virtually certain your solution
will not require you to actually debug R libraries to detect the seg
fault. It is much more likely you have 2 incompatible copies of the
same thing installed in various package folders, or that some
libraries in your Ubuntu collection are version -mismatched, but they
don't know it yet.  Usually that kind of problem works itself out
quickly as new versions of libraries are released.

Regards
pj



-- 
Paul E. Johnson
Professor, Political Science      Assoc. Director
1541 Lilac Lane, Room 504      Center for Research Methods
University of Kansas                 University of Kansas
http://pj.freefaculty.org               http://quant.ku.edu