Hi together,once or twice a year I try to compile R (www.r-project.org) for my C760. For compilation of R gcc and g77 are needed and later the R-binary is used to compile further modules (which makes it diffult to build with a cross-compiler My latest attempt was a native compilation based on OZ 3.5.4.1 (gpe) and the native sdk + additional packages as listed in the OZ wiki.Configuration and compilation was without problems until linking of the main R binary.Linking failed with the following message:

Hoi,I looked at the sources in src/main too. In some of the files I see #include <errno.h> , in others it is missing, although errno is used. I already included errno.h in all the files where errno is used, but that did not change anything.

In any case, I can reproduce the behaviour with two slightly different setups:

1) my C760 with OZ 3.5.4.1 (gpe) and the native-sdk-toolchain plus the additional packages from lardmans list: http://wiki.openzaurus.org/HowTos/Native_Development(inlcuding the packages for X11 developement and g77 and libreadline) I installed everything on my SD-card. For whatever reason (probably I did by mstake not use a "real" root shell, but used root login via su instead) some symboliks links were broken. But it was straightforward to repair them manually.

2) I tried it also with qemu and Poky (see here http://www.o-hand.com/~richard/qemu.html)Additionally to the sdk already included in the poky image, I installed (everything from the OZ 3.5.4.1 feed):g++_3.4.4-r5_arm.ipk g++-uc_0.1.9-r1_arm.ipk libgmp3_4.1.4-r0_arm.ipk mpfr-dev_2.1.1-r1_arm.ipkg77_3.4.4-r5_arm.ipk ldd_2.3.5+cvs20050627-r3_arm.ipk libgmp-dev_4.1.4-r0_arm.ipkg77-symlinks_3.4.4-r5_arm.ipk libg2c0_3.4.4-r3_arm.ipk libreadline4_4.3-r2_arm.ipkg++-symlinks_3.4.4-r5_arm.ipk libg2c-dev_3.4.4-r5_arm.ipk libreadline-dev_4.3-r2_arm.ipk

Both systems give exactly the same behaviour, thats why I think the problem is not related to the broken symlinks on my C760.

Adding a bug to the bugtracker does not seem necessary...It seems that the bug was resolved a (short?) while ago. According to here: http://bugs.openembedded.org/show_bug.cgi?id=43 glibc-2.3.5+cvs20050627-r11 should contain a working libc.so.

The need to pass ac_cv_c_bigendian=yes to configure is related to the fact that the current OZ soft-float implementation, fpa, keeps all fp numbers in bigendian format in memory. Therefore R needs to be told this. I do wonder what this will do when writing to files as R will think it's on a bigendian system. The same is true of Octave, but it automatically checks the endianness (iirc), again by looking at an fp number, so the same problem will probably manifest itself.

This will be sorted out when we move to Angstrom as eabi uses vfp, which keeps fp numbers in the same endianness as the processor.