[R-sig-Debian] Compiling R-2.11.0 with ATLAS-tuned BLAS and LAPACK

Andrew Piskorski atp at piskorski.com
Wed Jun 2 21:44:44 CEST 2010


On Wed, Jun 02, 2010 at 07:11:09AM -0500, Dirk Eddelbuettel wrote:

> On 2 June 2010 at 02:08, Andrew Piskorski wrote:
> | Dirk, that reminds me.  I DO build R myself from scratch, but it often
> 
> I'm curious -- Why?

Partly just historical practice; we started doing this on ancient
non-Debian-based Linux boxes where there wasn't any other option.
However, we also want to use the same exact version of R on different
machines, we want to be able to upgrade to the bug-fix ("patched")
branch versions of R on our own schedule, and we like the capability
to deploy our own modified R if necessary.

Also, and more concretely, some of our own in-house compiled code, due
to its own dependencies on other libraries, insists on having R linked
in particular ways.  One of our *.so shared libraries has always ran
fine with R's default build process, but gdb would then gets terribly
confused by the fact that our *.so is using some libraries which
themselves may be internally multi-threaded.  gdb would completely
break, saying only:

  [Thread debugging using libthread_db enabled] 
  Error while reading shared library symbols: 
  Cannot find new threads: generic error 
  (gdb) 

That's why I build R with "LIBS=-lpthread", it fixes that gdb problem.
The "--enable-threads" didn't seem to actually have any effect, but I
figured it might be safer to include it too.

> You could peek into my my obviously public configure call (by looking at
> debian/rules), I use --with-blas and --with-lapack and you differ in at least

Actually I had, by building the *.deb package on my laptop, but I
overlooked your use of --with-lapack, thanks!  (Also thanks for the
debian/rules hint; I've never dug into the guts of Debian packages
before.)

Btw, as far as patching the R sources, right now we don't.  Our
modifications are done solely after the fact by attaching a library of
rather nasty R code which purposely shadows some base R functions,
including "[.data.frame" and "[".  But Some Day, I will dig into the R
C code to figure out how to optionally make it do what we need
directly and cleanly.

The ugly parts in our shadowing functions, incidentally, are mostly
about not gratuitiously discarding names.  We need the old-fashioned
behavior of the 1990s era S, prior to some ill-advised changes by
Insightful, where names on data frames and matrices are preserved
whenever possible and only discarded when explicitly requested by the
programmer.  R unfortunately seemed to adopt the post-Insightful
S-Plus behavior where subscripting sometimes preserves names and
sometimes doesn't.

-- 
Andrew Piskorski <atp at piskorski.com>
http://www.piskorski.com/



More information about the R-SIG-Debian mailing list