Updated my R install on my GNU/Linux boxes (running CentOS 6.8) from 3.2.x -> 3.3.0, using latest from epel (i.e., not compiling from source), and while said upgrade seemed to go fine, am now (post-upgrade) having all sorts of problems with getting some (but not all) packages to compile (either during an initial install attempt, or upgrade to existing packages). For example, if I try to update nlme, I get the following errors, which are pretty well fatal: gcc: error: /builddir/build/BUILD/R-3.3.0/zlib-1.2.8/target/usr/lib64/libz.a: No such file or directory gcc: error: /builddir/build/BUILD/R-3.3.0/bzip2-1.0.6/target/usr/lib64/libbz2.a: No such file or directory gcc: error: /builddir/build/BUILD/R-3.3.0/xz-5.2.2/target/usr/lib64/liblzma.a: No such file or directory gcc: error: /builddir/build/BUILD/R-3.3.0/pcre-8.38/target/usr/lib64/libpcre.a: No such file or directory gcc: error: /builddir/build/BUILD/R-3.3.0/curl-7.48.0/target/usr/lib64/libcurl.a: No such file or directory Even I try this using devtools-4 (which gives me gcc/gfortran 5.2.1), same problem. I think the clue is the version of the libs the installer seems to be looking for. For example, zlib-1.2.8. RHEL only supports zlib-1.2.3-29. [Interesting, all of the static .a libs aren't on the system, by all the .so lib files for each of those listed above are installed]. Serious pain in the butt. R 3.2.5 was working perfectly -- upgrade pretty much gummed things up, as far as compiling some packages. What I don't understand is -- wouldn't packages like nmle (which are core packages in R) be configured for your specific RHEL distribution to have dependencies that are compatible? Either that, or I'm missing something completely. Thanks in advance.
problems compiling packages | 3.3.0 | Linux
5 messages · Tom Callaway, Evan Cooch
1 day later
On 06/04/2016 12:10 PM, Evan Cooch wrote:
Updated my R install on my GNU/Linux boxes (running CentOS 6.8) from 3.2.x -> 3.3.0, using latest from epel (i.e., not compiling from source), and while said upgrade seemed to go fine, am now (post-upgrade) having all sorts of problems with getting some (but not all) packages to compile (either during an initial install attempt, or upgrade to existing packages).
Here's what happened: In R 3.3.0, R requires much newer versions of zlib, bzip2, lzma/xz. curl, and pcre than are included in EL5/6. Since I suspected strongly that people would not like the answer of "upgrade to EL7" (though, to be fair, you really should seriously consider that), I endeavoured to hack in bundled copies of those needed libs, compiled statically into R. Unfortunately, this process had some leftover noise, which resulted in my giant pile of custom LDFLAGS getting inherited when you build from CRAN. 3.3.0-5 _should_ resolve all of this and "just work". Please test this build when it finishes and let me know: http://koji.fedoraproject.org/koji/taskinfo?taskID=14394314 Thanks, ~tom == Red Hat
Thanks very much. I had more or less reached the same conclusions -- I was just about to rebuild RPMs for source for zlib, etc, and update those, and try again, but I've had mixed success in doing that in past. Its easy enough to roll back to 3.2.5 (which compiles perfectly against all the CentOS 6.x.x libs), but 3.30 plays nice with a few other things I work with. Hence my interest in 3.30. I'll definitely try the latest build later this week. p.s. I should probably upgrade to RH 7 - but thanks for not beating me over the head with the obvious. ;-)
On 6/6/2016 9:55 AM, Tom Callaway wrote:
On 06/04/2016 12:10 PM, Evan Cooch wrote:
Updated my R install on my GNU/Linux boxes (running CentOS 6.8) from 3.2.x -> 3.3.0, using latest from epel (i.e., not compiling from source), and while said upgrade seemed to go fine, am now (post-upgrade) having all sorts of problems with getting some (but not all) packages to compile (either during an initial install attempt, or upgrade to existing packages).
Here's what happened: In R 3.3.0, R requires much newer versions of zlib, bzip2, lzma/xz. curl, and pcre than are included in EL5/6. Since I suspected strongly that people would not like the answer of "upgrade to EL7" (though, to be fair, you really should seriously consider that), I endeavoured to hack in bundled copies of those needed libs, compiled statically into R. Unfortunately, this process had some leftover noise, which resulted in my giant pile of custom LDFLAGS getting inherited when you build from CRAN. 3.3.0-5 _should_ resolve all of this and "just work". Please test this build when it finishes and let me know: http://koji.fedoraproject.org/koji/taskinfo?taskID=14394314 Thanks, ~tom == Red Hat
On 06/06/2016 10:00 AM, Evan Cooch wrote:
Thanks very much. I had more or less reached the same conclusions -- I was just about to rebuild RPMs for source for zlib, etc, and update those, and try again, but I've had mixed success in doing that in past. Its easy enough to roll back to 3.2.5 (which compiles perfectly against all the CentOS 6.x.x libs), but 3.30 plays nice with a few other things I work with. Hence my interest in 3.30.
Yeah. I thought about pulling it all into a separate copr repo with updated packages, but EL5/6 are fragile as is, without me introducing major API changes to core libraries. Last thing I need in my life is Red Hat Support angry at me for breaking people's RHEL boxes. :) This solution was the best option I could come up with from a list of bad options. ~tom == Red Hat
Understood. Thanks for the feedback.
On 6/6/2016 10:04 AM, Tom Callaway wrote:
On 06/06/2016 10:00 AM, Evan Cooch wrote:
Thanks very much. I had more or less reached the same conclusions -- I was just about to rebuild RPMs for source for zlib, etc, and update those, and try again, but I've had mixed success in doing that in past. Its easy enough to roll back to 3.2.5 (which compiles perfectly against all the CentOS 6.x.x libs), but 3.30 plays nice with a few other things I work with. Hence my interest in 3.30.
Yeah. I thought about pulling it all into a separate copr repo with updated packages, but EL5/6 are fragile as is, without me introducing major API changes to core libraries. Last thing I need in my life is Red Hat Support angry at me for breaking people's RHEL boxes. :) This solution was the best option I could come up with from a list of bad options. ~tom == Red Hat