I'm using the openembedded build tools (www.openembedded.org) to build
a system for a Zaurus SL-6000L [aka a "tosa"]. I'm using a recent
update of the org.openembedded.dev tree (openembedded uses monotone
for revision control). I edited the packages/gcc/gcc3-build.inc file
and added ",java" to the JAVA_arm variable so that it would build gcj,
and in my local.conf file I set:
PREFERRED_VERSION_gcc = "4.1.1"
PREFERRED_VERSION_gcc-cross = "4.1.1"
PREFERRED_VERSION_gcc-cross-initial = "4.1.1"
so that it would use gcc4.1.1. I'm running a 2.6 kernel on the
SL-6000L, which is still considered a work in progress.
I can compile and link a simple Hello world program as follows:
gcc -c Hello.java
gcc --main=Hello -o Hello Hello.o
Then move the resulting executable and libgcj.so.7 over to the Zaurus
and set LD_LIBRARY_PATH=. so that it can find libgcj.
It blows up the first several times that I try to run it but
eventually runs successfully.
This time around (after rebooting) it said:
Aborted
then the second time:
Illegal Instruction
then the third run:
Exception during runtime initialization
java.lang.ExceptionInInitializerError
<<No stacktrace available>>
Caused by java.lang.NullPointerException
<<No stacktrace available>>
and finally
Hello there.
Once it's run successfully then it seems to continue to run
correctly. I've also seen it crash with a "Segmentation fault".
I've seen posts describing two arm related problems in the boehm-gc
library, one that changes how it finds the bottom of the stack from
"HEURISTIC1" to "LINUX_STACKBOTTOM" and one that makes a small change
to the test-and-set function. Both changes seem to be in the gcc
4.1.1 tree that I'm using.
The system is using "glibc-2.3.5+cvs20050627-r7" and
"binutils-cross-2.16-r7".
I originally tried using gcc-3.4.4 and had the same problems (even
after confirming/adding the two fixed described above).
Does the behaviour I'm describing above sound familiar to anyone?
What extra information can I provide to help figure out what's going
wrong?