Hello All, The link to the binary & installation instructions (tar.gz binary not an ipk I'm afraid) is as follows: http://students.bath.ac.uk/enpsgp/Zaurus/#R It eventually dawned on me that the WORDS_BIGENDIAN define (or lack thereof) was causing the problems (after testing ieee NaN compliance that is). When cross-compiling it's probably fair enough that the configure script can't work out what the endianness should be, however the same thing happened (WORDS_BIGENDIAN not defined) when compiling on an ARM machine (one of the iPAQ skiff cluster machines. See http://www.handhelds.org/z/wiki/SkiffCluster) The following is the section of the config.log pertaining to determining endianness, for those who may want to try to fix/alter the configure script (from the ARM iPAQ machine): ============================================================= configure:12298: checking whether byte ordering is bigendian configure:12328: gcc -c -g -O2 -I/usr/local/include conftest.c >&5 configure:12331: $? = 0 configure:12334: test -s conftest.o configure:12337: $? = 0 configure:12364: gcc -c -g -O2 -I/usr/local/include conftest.c >&5 configure: In function `main': configure:12354: `not' undeclared (first use in this function) configure:12354: (Each undeclared identifier is reported only once configure:12354: for each function it appears in.) configure:12354: parse error before `big' configure:12367: $? = 1 configure: failed program was: #line 12340 "configure" #include "confdefs.h" #include <sys/types.h> #include <sys/param.h> #ifdef F77_DUMMY_MAIN # ifdef __cplusplus extern "C" # endif int F77_DUMMY_MAIN() { return 1; } #endif int main () { #if BYTE_ORDER != BIG_ENDIAN not big endian #endif ; return 0; } configure:12481: result: no ============================================================= Might be something to do with the /sys/ tacked on the front of the types.h and param.h includes? In any case if you just want it to compile then use something like the following: $ ./configure --host=arm-linux --build=i686-mandrake-linux ac_cv_c_bigendian=yes I've not tested the X parts of R yet, nor have I done anything else other than making sure that NAs are handled correctly. Happy new year to you all, Simon -------------------------------------------- Simon Pickering MEng Dept. of Mechanical Engineering University of Bath Bath, BA2 7AY, UK Tel: +44 (0)1225 383314 Fax: +44 (0)1225 386928 --------------------------------------------
R on the Zaurus link
2 messages · Simon Pickering, Peter Dalgaard
Simon Pickering <enpsgp at bath.ac.uk> writes:
#include "confdefs.h"
#include <sys/types.h>
#include <sys/param.h>
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
#if BYTE_ORDER != BIG_ENDIAN
not big endian
#endif
;
return 0;
}
configure:12481: result: no
=============================================================
Might be something to do with the /sys/ tacked on the front of the types.h
and param.h includes?
I don't think so, but the test looks dubious: at least on i386-Linux, it is __BYTE_ORDER and __BIG_ENDIAN, unless you include endian.h.
O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907