Upgrade R to version 3.0.2

[EmmanuelCharpentier]

New spkg: http://boxen.math.washington.edu/home/jpflori/spkg/r-3.0.2.p0.spkg

r-3.0.2.p0 (Jean-Pierre Flori, 30 October 2013)

• Upgrade R to version 3.0.2 #14706: update to 3.0.2.
• Remove sqrtl.patch which is now upstream.
• Move old install on OS X.
• Fix visibility of symbols in built-in libintl.

r-3.0.1.p1 (Jean-Pierre Flori, 10 June 2013)

• Upgrade R to version 3.0.2 #14706: Use --disable-long-double on Cygwin rather than patching.
• Add sqrtl.patch from upstream to make --disable-long-double work.

r-3.0.1.p0 (Emmanuel Charpentier, 8 June 2013)

• Upgrade R to version 3.0.2 #14706: Drop-in replacement of upstream sources.

---

Apply: attachment: trac_14706-version.patch

Upstream: Reported upstream. No feedback yet.

CC: @SnarkBoojum

Component: packages: standard

Keywords: r-project spkg

Author: Emmanuel Charpentier, Jean-Pierre Flori

Reviewer: Leif Leonhardy, Karl-Dieter Crisman, Jeroen Demeyer, John Palmieri

Merged: sage-5.13.beta4

Issue created by migration from https://trac.sagemath.org/ticket/14706

[nexttime]

comment:1

For the record: Removing -L$SAGE_LOCAL/lib from LDFLAGS (#13443) recently broke building R on CentOS, cf. [#13443 comment:12] and sage-devel.

[nexttime]

Changed keywords from r-project to r-project spkg

[jdemeyer]

Replying to @EmmanuelCharpentier:

This ticket is a place where I plan to send new updates to the R version used in Sage (R is, in principle, updated every six months). So I intend to open, close, reopen... as long as newer versions do not entail any substantial modification beyond dropping new R source in place and fixing the expected version numbers in the r.py doctest. Any further problems should be reported in specific tickets. As a new R version arrives (and Real Life (TM) allowing), I'll start from the last accepted patch for this spkg...

This is routine work (i. e. even I can do it:-), but using an up-to-date R interpreter is a sine qua non for reporting problems to R core, so it probably has to be done for Sage users to get answers from R core.

I honestly don't understand anything of this ticket description. What is this ticket about???

[nexttime]

comment:4

Replying to @jdemeyer:

I honestly don't understand anything of this ticket description. What is this ticket about???

Atm upgrading R to 3.0.1 it seems...

[EmmanuelCharpentier]

comment:5

• Status changed from new to needs_review

1. New spkg : available on Google drive (https://docs.google.com/file/d/0B1gfn4_V_wm3clctVFFhUnlINVU/edit?usp=sharing)

2. What this ticket is about :

a) Having an up-to-date R is a sine qua non to get answers from R Core.

b) R in Sage is rarely up to date (more talented Sage developers work on more important issues).

c) Therefore, R-in-Sage users have trouble communicating with R Core

d) I am able to create "drop-in replacements" of the R spkg, thus giving R-in-Sage users an up-to-date R, thus allowing them to get answers from R Core...

e) Since this is routine work that few people seem to tackle, and since it is in my limited ability range, I'll try to do it after R upstream upgrades.

Is that clearer ?

[jdemeyer]

comment:8

Replying to @EmmanuelCharpentier:

Is that clearer ?

Why not just say "Upgrade R to version 3.0.1" like leif said?

For the spkg, I really need a URL to the spkg, not some link to some website where I have to click on something...

Also: fill in your real name as Author.

[nexttime]

comment:9

Replying to @jdemeyer:

For the spkg, I really need a URL to the spkg, not some link to some website where I have to click on something...

There's btw. http://spkg-upload.googlecode.com...

[nexttime]

Author: Emmanuel Charpentier

[nexttime]

comment:10

... and feel free to add yourself to the list of developers on the Sage wiki.

[EmmanuelCharpentier]

comment:11

Replying to @jdemeyer:

Replying to @EmmanuelCharpentier :

Is that clearer ?

Why not just say "Upgrade R to version 3.0.1" like leif said?

Because I intend to re-open/re-close it as upstream spits out new versions... I see no point in cluttering the ticket stream with identical repeats of the same trivial point...

For the spkg, I really need a URL to the spkg, not some link to some website where I have to click on something...

Upload in progress as I write this (I hadn't yet credentials for spkg-uploads)

Also: fill in your real name as Author.

If you say so...

[EmmanuelCharpentier]

comment:12

Spkg uploaded to spkg-uploads :

https://code.google.com/p/spkg-upload/downloads/detail?name=r-3.0.1-p0.spkg&can=2&q=

[jdemeyer]

comment:13

Replying to @EmmanuelCharpentier:

Because I intend to re-open/re-close it as upstream spits out new versions...

That's not allowed. A closed ticket also serves as a reference for when a particular package was merged in a particular Sage version, and the comments show any issues which appeared. If different upgrades would happen on one ticket, that would be a mess.

Standard practice is to create a new ticket for every upgrade. However, as long as the new package is not yet merged into Sage, you can change the ticket. Imagine that R 3.0.2 comes out today, you can change this ticket to upgrade to R 3.0.2 (since this ticket isn't merged yet).

[nexttime]

comment:16

Replying to @EmmanuelCharpentier:

Spkg uploaded to spkg-uploads :

https://code.google.com/p/spkg-upload/downloads/detail?name=r-3.0.1-p0.spkg&can=2&q=

Could you please rename the file to r-3.0.1**.**p0.spkg?

(IIRC, renaming isn't possible there, so that would mean: rename your local file, (re)upload it, and delete the old one there.)

[jpflori]

Attachment: r-3.0.2.p0.diff.gz

Spkg diff, for review only.

[jpflori]

comment:112

Hopefully, I fixed the problem.
The Matrix module wants to use the gettext dngettext function.
On usual system this is provided by the system libc or the system libintl.
On Solaris the system libintl does not provide it so R decides to build its own libintl (in src/extra/intl) but with symbols hidden by default (-fvisibility-hidden) and only publicize a few of them, but not dngettext.
So I treated that last function as the few others one already visible.

spkg at same address.
diff updated.

[jpflori]

comment:113

• Non-standard location readline problem reported as https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15556
• Solaris gettext problem as https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15555

[jpflori]

Upstream: Reported upstream. No feedback yet.

[jdemeyer]

comment:114

Nitpick about the library patch: the second r.version() should be r_version(). By the way, I wouldn't mind deprecating r_version() since I really don't see the point. It would be consistent with the deprecation of gap_version().

[jpflori]

comment:115

Attachment: trac_14706-version.patch.gz

Patch updated.

Sure, I have nothing agains deprecating r_version which seems not so useful.
But I won't have time to do it right now and this is not really the scope of this ticket, so two good reasons to do that in a follow-up ticket.

[kcrisman]

comment:116

See the discussion at #13686 as well (and perhaps elsewhere?) on the R version function issue.

[jdemeyer]

Merged: sage-5.13.beta4

[mezzarobba]

comment:119

Shouldn't r-3.0.2 be available from http://www.sagemath.org/packages/upstream/r/r-3.0.2.tar so that the build system of the git master branch can download it automatically?

[jpflori]

comment:120

I've no idea who is in charge of maintaining packages/upstream, nor if it's automatically updated when Mercurial releases are merged into the git repo, nor how we should upload future tarballs when we're in git-only mode (in particular note that some tarball are not upstream one's, maybe all dependencies should now have spkg-src which automate the creation of the tarballs --- vanilla or not).

[mezzarobba]

comment:121

Ok, thanks for your reply. I also added a comment on the issue at #14480 comment:51, so hopefully someone who knows where to find the right version can upload it!

[jpflori]

comment:122

I've posted on sage-git where it might receive more attention:

• https://groups.google.com/d/msg/sage-git/wyM7OSZcw2E/gbVNVq0KaKIJ

[jpflori]

comment:123

Replying to @jpflori:

• Non-standard location readline problem reported as https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15556

Upstream answered: you're the first one to report that in 15 years, unless you provide a patch we don't care.

• Solaris gettext problem as https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15555

This has been fixed in R trunk.

[dimpase]

Attachment: arm-r-3.0.2.p0.log

log on an ARM system

[dimpase]

comment:124

I am trying to build Sage 6.0 on a ARM system I just got access to, and it fails with a strange error. See the corr. attachment for the full log.

begin installing recommended package lattice
* installing *source* package 'lattice' ...
** package 'lattice' successfully unpacked and MD5 sums checked
** libs
make[6]: Entering directory `/tmp/Rtmpu7TiBm/R.INSTALL74b515accca6/lattice/src'
gcc -std=gnu99 -I/home/dimpase/sage/sage/local/var/tmp/sage/build/r-3.0.2.p0/src
/include -DNDEBUG      -fpic  -g -O2   -c init.c -o init.o
gcc -std=gnu99 -I/home/dimpase/sage/sage/local/var/tmp/sage/build/r-3.0.2.p0/src
/include -DNDEBUG      -fpic  -g -O2   -c threeDplot.c -o threeDplot.o
gcc -std=gnu99 -shared -L/home/dimpase/sage/sage/local/lib/ -o latticeSHLIB_EXT 
init.o threeDplot.o SHLIB_LIBADD -L/home/dimpase/sage/sage/local/var/tmp/sage/bu
ild/r-3.0.2.p0/src/lib -lR
gcc: error: SHLIB_LIBADD: No such file or directory
make[6]: *** [latticeSHLIB_EXT] Error 1
make[6]: Leaving directory `/tmp/Rtmpu7TiBm/R.INSTALL74b515accca6/lattice/src'
ERROR: compilation failed for package 'lattice'
* removing '/home/dimpase/sage/sage/local/var/tmp/sage/build/r-3.0.2.p0/src/library/lattice'
make[5]: *** [lattice.ts] Error 1

[vbraun]

comment:125

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679180 for an analysis and patch of the SHLIB_LIBADD issue

[dimpase]

comment:126

Replying to @vbraun:

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679180 for an analysis and patch of the SHLIB_LIBADD issue

Anyone familiar with R building system around?
I tried this, and got weird stuff:

** package 'lattice' successfully unpacked and MD5 sums checked
** libs
make[6]: Entering directory `/tmp/RtmpYoKYEk/R.INSTALL57a933daa9d6/lattice/src'
gcc -std=gnu99 -I/home/dimpase/sage/sage/local/var/tmp/sage/build/r-3.0.2.p0/src/include -DNDEBUG 
     -fpic  -g -O2   -c init.c -o init.o
gcc -std=gnu99 -I/home/dimpase/sage/sage/local/var/tmp/sage/build/r-3.0.2.p0/src/include -DNDEBUG 
     -fpic  -g -O2   -c threeDplot.c -o threeDplot.o
gcc -std=gnu99 -shared -L/home/dimpase/sage/sage/local/lib/ -o latticeSHLIB_EXT init.o threeDplot.
o -L/home/dimpase/sage/sage/local/var/tmp/sage/build/r-3.0.2.p0/src/lib -lR
gcc -std=gnu99 -shared -L/home/dimpase/sage/sage/local/lib/ -o .so init.o threeDplot.o -L/home/dim
pase/sage/sage/local/var/tmp/sage/build/r-3.0.2.p0/src/lib -lR
make[6]: Leaving directory `/tmp/RtmpYoKYEk/R.INSTALL57a933daa9d6/lattice/src'

note that linker is called twice, once with -o latticeSHLIB_EXT, and then with -o .so !? wtf...
I can only speculate that the generation of SHLIB_EXT is still broken and injects unprintable chars into the string, which leads to the linking command executed twice.

[dimpase]

comment:127

Replying to @dimpase:

Replying to @vbraun:

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679180 for an analysis and patch of the SHLIB_LIBADD issue

Anyone familiar with R building system around?
I tried this, and got weird stuff:

it turns out that SHLIB_EXT is set up in more than 1 place in install.R. So this workaround has to be done for all these places to work right.

I've opened a new ticket with the patch. See #15762.

[EmmanuelCharpentier]

comment:128

Dear co-authors,

Please have a look at Trac#16694, whoch might be germane to your work and solution.

Emmanuel Charpentier