similar to: Building R under Linux - library dependencies

> | Is there a way to overcome this problem? Precompiled versions of R can be installed on various system configurations, so I guess that there should be a way to compile it in a version-agnostic manner. > > Yes, for example by > > -- using a Docker container which is portable across OSs (!!) and versions Docker R containers are north of 250 MB. I have checked experimentally

What do you have installed as far as libcurl goes? Would you mind listing your packages and greping for libcurl entries. Perhaps I need some libcurl debs installed when I install r-base? On Thu, Nov 5, 2015 at 11:34 AM, Dirk Eddelbuettel <edd at debian.org> wrote: > > On 5 November 2015 at 11:11, Michael Coyne wrote: > | Hello, > | > | I'm install R from a package off of

Thanks for the advice. Going to look into this more this evening and hopefully get everything working. Thanks again! On Thu, Nov 5, 2015 at 11:56 AM, Dirk Eddelbuettel <edd at debian.org> wrote: > > On 5 November 2015 at 11:44, Michael Coyne wrote: > | What do you have installed as far as libcurl goes? Would you mind > | listing your packages and greping for libcurl entries.

I am unable to install R on an up to date (i.e. apt upgraded) Ubuntu 14.04 system. According to https://cran.r-project.org/bin/linux/ubuntu/README (and many other sources), R is available for this version of Ubuntu (which is a stable version). I currently have deb https://cran.cnr.berkeley.edu/bin/linux/ubuntu trusty/ in sources.list. I've tried this with and without deb

I can make a few suggestions to help you hunt for the issue. This kind of error is often caused by conflicting packages from proposed, backports, ppas, or other 3rd party repos. If for some reason you have a dependency installed from one of those sources that is newer than what R on cran was built against (stock ubuntu 14.04) then you will hit a conflict. Simply removing backports from your repos

Possibly off the wall and a long shot, but is pre-installed Linux perhaps 32 bit, while the R attempt is 64? JN On 16-03-23 02:22 PM, Barnet Wagman wrote: > Synaptic can show the origin of packages. > > The only thing I see from a backport is > > libcmanager0 > > I don't think this is relevant to R. Or is it. > > The only thing I've got installed from

On 7 September 2016 at 17:27, Pawe? Pi?tkowski wrote: | Hello and apologies if this doesn't belong here. | | I'm trying to build a "portable" version of R - "portable" means that it could be easily moved to another location or machine simply by copying it. However, I encountered a problem when running it elsewhere: it seems that versions of dynamic libraries used by R

That could do it http://packages.ubuntu.com/trusty-backports/libcgmanager0 Seems to be libc related, which is a pretty core library to much of the whole system. Hmm, which model Dell? We just got a Dell 5000 series with Ubuntu, I have not checked with my boss if there was R installation issues. Thanks, Alex On 03/23/2016 11:22 AM, Barnet Wagman wrote: > Synaptic can show the origin of

Hi, I am having trouble building R static on Solaris 5.10. I have a requirement to run R within a specific user account on Solaris 5.10 and I do not have access to compilers and or shared libraries on the target machine. I thought I could build R static ( I've build it locally on Solaris with shared libraries) and just ftp the build to the target Solaris box. Can any help with what

Been and R-user for about 5 years now in an industrial setting, and always find the mailing list most helpful. I have run into problem compiling igraph on R. I have contacted the maintainer of igraph, and he has determined that it is not an igraph problem. System is FreeBSD 7.2, R-2.10.1 [also have a sandbox machine running FreeBSD 7.3, R-2.11]. Both machines fail the installation of igraph.

Dear R-SIG-Debian, I am using R version 3.1.2 with rstudio-server 0.98.113 on debian build 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64 GNU/Linux. I often use the %dopar% operator in from the foreach package to run code in parallel. However, the only other use on the box seemingly installed a few items and suddenly %dopar% will use far more than the number of cores I am specifying and

On Wed, 2015-09-02 at 20:49 +0200, arnaud gaboury wrote: > On Wed, Sep 2, 2015 at 7:35 PM, arnaud gaboury <arnaud.gaboury at gmail.com> wrote: > > After a few days of reading and headache, I finally gave a try at > > building R from source with Intel MKL and ICC. Documentation and posts > > on this topic are rather incomplete, sometime fantasist et do not give > >

After a few days of reading and headache, I finally gave a try at building R from source with Intel MKL and ICC. Documentation and posts on this topic are rather incomplete, sometime fantasist et do not give much explanations about configure options. As I am not sure if mine is correct, I would appreciate some advices and hints. OS: Fedora 22 parallel_studio_xe_2016 Hardware : 8 Thread(s) per

I just built R-devel from source on OS X (Tiger), using the subversion sources. Running ./tools/rsync-recommended didn't download rcompgen. I checked http://cran.r-project/src/contrib/2.7.0/Recommended and indeed, this package is not there. If I try to install using install.packages I get > install.packages("rcompgen", type="source") --- Please select a CRAN

Hi all I'm updating a package for submission to CRAN, and I am getting an error message I never have seen before, and can't find out what it implies or means (and hence, what I need to do to fix it). After running R CMD check, I get this: <snip> * checking foreign function calls ... OK * checking R code for possible problems ... OK * checking Rd files ... OK * checking Rd

On Tue, Sep 29, 2015 at 8:11 PM, Nathan Kurz <nate at verse.com> wrote: > Hi Arnaud -- > > I'm glad it's working for you. I'm not sure I understand your final > answer. Are you saying that the version I posted worked for you as > given, or that you had to remove some of the other options? I say it works perfectly when using the single dynamic library (lmkl_rt):

Got a problem with one workstation. What I'm seeing, from a yum update (saw it with make whatis first): <snip> Running rpm_check_debug error: rpmdbNextIterator: skipping h# 1211 hdr SHA1: BAD, not hex <repeated many times> <snip> ERROR with rpm_check_debug vs depsolve: libicui18n.so.36 is needed by boost-1.33.1-10.el5_7.3.i386 libicuuc.so.36 is needed by

+stable@ Yoshihiro Ota wrote: > Why are so many people are bitten by this? Is that the jobs of port-upgrading > tool to safe copy these libraries to compat so that all programs using > the old libraries works? Portupgrade preserves the libraries in /usr/local/lib/compat/pkg: % ls /usr/local/lib/compat/pkg/ libicudata.so.36.0 libicule.so.36.0 libicuuc.so.36.0

Dear all, can somebody point me from where to download "rcompgen" package? CRAN does not seem to hold that. Installing this package through install.packages() tells this package is not available. Thanks [[alternative HTML version deleted]]

I just uploaded R 2.5.0 to Debian's unstable distribution. As Peter's announcement says, it now contains two new packages'rcompgen' and 'codetools'. About two or three weeks ago, I also packaged these, just like other 'recommended' packages as r-cran-rcompgen and r-cran-codetools. However, as "new" packages, they are still in the NEW queue awaiting