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:

gcc -Wl,--export-dynamic -L/usr/local/lib -o R.bin Rmain.o CConverters.o CommandLineArgs.o Rdynload.o Renviron.o RNG.o apply.o arithmetic.o apse.o array.o attrib.o base.o bind.o builtin.o character.o coerce.o colors.o complex.o connections.o context.o cov.o cum.o dcf.o datetime.o debug.o deparse.o deriv.o dotcode.o dounzip.o dstruct.o duplicate.o engine.o envir.o errors.o eval.o format.o fourier.o gevents.o gram.o gram-ex.o graphics.o identical.o internet.o iosupport.o lapack.o list.o localecharset.o logic.o main.o mapply.o match.o memory.o model.o names.o objects.o optim.o optimize.o options.o par.o paste.o pcre.o platform.o plot.o plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o qsort.o random.o regex.o registration.o relop.o rlocale.o saveload.o scan.o seq.o serialize.o size.o sort.o source.o split.o sprintf.o startup.o subassign.o subscript.o subset.o summary.o sysutils.o unique.o util.o version.o vfonts.o xxxpr.o ../unix/libunix.a ../appl/libappl.a ../nmath/libnmath.a -L../../lib -lRblas -lg2c -lm -lgcc_s ../extra/zlib/libz.a ../extra/bzip2/libbz2.a ../extra/pcre/libpcre.a -lreadline -ldl -lm
/lib/ld-linux.so.2: undefined reference to `errno'
collect2: ld returned 1 exit status

At the moment I have no idea if this is related to R or if it is a OZ problem. Did someone encounter a similar problem before?
Many thanks, Georg

Does this error mean that the declaration of errno has not been performed?

Some places to look:

src/main/source.c has "/* extern int errno; No longer used */"
src/main/dounzip.c does have a declaration of errno:



Which seems to indicate that errno.h ought to be declared in there...?

I'm not too sure how to get GCC to spit out some more information about where it's not found the declaration (assuming that's what it is). Anyone?

Georg,

Did you need to do anything special to setup your toolchain? Would you mind posting instructions for which ipks were needed?

Thanks,


Si

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.ipk
g77_3.4.4-r5_arm.ipk
ldd_2.3.5+cvs20050627-r3_arm.ipk
libgmp-dev_4.1.4-r0_arm.ipk
g77-symlinks_3.4.4-r5_arm.ipk
libg2c0_3.4.4-r3_arm.ipk
libreadline4_4.3-r2_arm.ipk
g++-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.

Hoi again,

I found a way to get it working. The hack is described here:
http://www.oesf.org/forums/index.php?showt...t=&#entry117262

I changed /usr/lib/libc.so as it is described there.

I am only a stupid user, is htis now a bug or a feature?

Compilation failed now on another point due to a missing package. In any case, I let you know how far I come with building R.
Thanks for your efforts, Georg

Sounds like it's probably a bug.

Can you add it to the bugtracker please (assuming it's not already there of course)? http://bugs.openembedded.org/

I'm looking forward to trying out your newly compiled version of R


Si

That's why I made a custom script to install gcc and related packages plus do all the required configurations.

Editing of libc.so is NOT needed. You need binutils 2.16 installed - they are provided in upgrades feed.

I did a "ipkg update; ipkg upgrade" before starting the whole compilation process and I just checked it again, I have binutils 2.16 installed:

# ipkg list_installed binu*
binutils - 2.16-r3 -
binutils-symlinks - 2.16-r3 -

I will file a bug-report later today. Thanks for your help, Georg

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.

Installed on OZ 3.5.4.1 is: libc6 - 2.3.5+cvs20050627-r3 (and the same versions of glibc.


And, building R seems to work now (it takes really long building the base modules;-) I will announce the availability in OZ/GPE once I am finished with compiling and testing.

Thanks for your helpfull suggestions and especially to lardman for his several years of work on this .

Georg

Glad you've got it sorted out

Si

One (random) point to note.

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.


Si

indeed in Angstrom, configure: loading site script /home/gordon/oe/org.openembedded.dev/site/endian-little