[R] R-2.0.0 on ARM (Sharp Zaurus)

Simon Pickering S.G.Pickering at bath.ac.uk
Sun Dec 12 15:17:36 CET 2004


Hi All,

I've recently dusted off my cross-compiling hat and decided to add R to the
OpenEmbedded build environment (this is used to build the
OpenZaurus/Familiar distributions for the Zaurus/iPAQ amongst other things -
I note there's also work underway to add the Psion 5mx etc. to
OpenEmbedded).

OpenEmbedded builds now use -soft-float which makes floating point
operations something like 10x faster than the previous GCC3.x implementation
which was itself faster than the GCC2.95 implementation of the original
Sharp and OpenZaurus ROMs. That means, for those of you with Zauruses, that
a switch from OZ3.2 (or any Sharp ROM) to the current OZ3.5.2 should produce
significant speed increases when using R; perhaps even enough to make it
usable/useful? Once I have a fully compiled version I'd be more than happy
to run some benchmarks.

Another thing to note with regards to usability, is that the OpenZaurus
distribution now also comes in the GPE (X11 based) flavour, so R should be
usable with all of its graphics. For those who want to stick with Opie
(Qtopia based), a new development, XQt - which allows X11 apps to run inside
a Qtopia/Opie window without needing to use VNC, as was previously the case
- is available and it works very well.

On to my progress...

As ever the configure script isn't overly happy cross-compiling. The problem
is the way in which LD_LIBRARY_PATH is altered (I note the FIXME comments
around this bit of code). I've patched the file to remove this for my
cross-build and it now works fine. I'm also passing ac_cv_bigendian=yes to
avoid the NA problem of old (I presume this is still necessary, I'll test
once I have a working binary).

The next issue is related to the compilation process's use of the R.bin
binary during the compilation. Obviously this doesn't work very well when
you're cross-compiling.

To try to get around this, I've created a native build of R as part of the
cross-build process. I currently get an error in R-2.0.0/src/library/base:

| make[3]: Entering directory
`/home/simon/dev/bk/build/tmp/work/r-2.0.0-r0/R-2.0.0/src/library/base'
| building package 'base'
| mkdir -p -- ../../../library/base/demo
| mkdir -p -- ../../../library/base/man
| Error in eval(expr, envir, enclos) : may already be using lazy loading on
base
| Execution halted
| make[3]: *** [all] Error 1
| make[3]: Leaving directory
`/home/simon/dev/bk/build/tmp/work/r-2.0.0-r0/R-2.0.0/src/library/base'
| make[2]: *** [R] Error 1
| make[2]: Leaving directory
`/home/simon/dev/bk/build/tmp/work/r-2.0.0-r0/R-2.0.0/src/library'
| make[1]: *** [R] Error 1
| make[1]: Leaving directory
`/home/simon/dev/bk/build/tmp/work/r-2.0.0-r0/R-2.0.0/src'
| make: *** [R] Error 1

Although I've no idea what it's trying to do here, my guess is that this
'lazy loading' has already been enabled on the native build (and this is
what R_EXE points to as I've patched all the Makefile.in files under
R-2.0.0/src/library), and therefore it's not happy trying to re-enable it on
the cross-build.

I'd appreciate it if someone could tell me whether my method (using the
native version of R to perform these steps) can even work (or does the ARM
version have to run these steps itself)? Assuming these steps build a
database of some sort, would it be possible to just copy across the native
built one? Would this work if placed in the correct location for the ARM
build? If the ARM version has to run these steps, could they be delayed
until it is installed and then run as a batch job?

Sorry for the long post and the many questions. I Hope this is of interest
to some of you, and that you might find a bit of time to help me out.

Many thanks,



Simon

----------------------------------------
Simon Pickering MEng
Research Officer
Materials Research Centre
Faculty of Engineering & Design
University of Bath
Bath, BA2 7AY, UK

Tel: +44 (0)1225 384802
Fax: +44 (0)1225 386928




More information about the R-help mailing list