I've been trying to use GCJ to ahead-of-time compile a Java app and have encountered a runtime problem. The app uses a custom JNI library for serial port access, and loading it is the source of my current trouble. I'm trying to find out if the current version of GCJ can do what I want. If it does, I'd appreciate guidance in tracking down the source of my problem. Now the details... The application is intended to run on an embedded system (ARM chip, Linux kernel 2.4.26, glibc 2.3.2), so it's a cross-compile. We have a commercial JVM option available, but I'm exploring GCJ as a possible alternative. I used Dan Kegel's Crosstool to set up my build environment with GCC 4.1.0, targeting arm-unknown-linux, glibc 2.3.2. This was recommended by the hardware vendor, and it's been working great for C/C++ components of the system. I successfully compiled and ran a simple hello-world Java app, but a more complex test app that uses the JNI library gives me an error: $ ./serialTerminal -c /dev/ttyS1 -b 9600 -p N -d 8 -s 1 os.name="Linux" os.arch="armv4l" pc : [<2aadb414>] lr : [<2b30d924>] Tainted: P sp : 7fffefb0 ip : 2bb14498 fp : 7ffff314 r10: 2aae4214 r9 : 00000001 r8 : 7f5fedbc r7 : 7f5ff09c r6 : 00000000 r5 : 7f5fedd8 r4 : 00000078 r3 : 00000000 r2 : 0000003c r1 : 7f5ff09c r0 : 7f5fedbc Flags: Nzcv IRQs on FIQs on Mode USER_32 Segment user Control: C000317F Table: 011F8000 DAC: 00000015 Error operating serial terminal: java.lang.NullPointerException java.lang.NullPointerException <<No stacktrace available>> Exiting... The os.name/os.arch output line and the "Error operating..." output are in app code. The rest appears to be dumped to root as part of shared library loading. The first line is generated just before "System.loadLibrary(libName)". The line just after loadLibrary() is not executed, so the NPE pretty clearly comes from the System call. In digging through the GCJ class source, I don't see any opportunity for a NullPointerException in the Java, so I think it's being thrown from the native code. I've used the -g flag to turn on line tracing and such, so I assume the lack of stacktrace is due to the native throw. The Status page for GCJ (http://gcc.gnu.org/java/status.html) indicates that file I/O for ARM is not yet supported, and only lists "Bare Metal ARM," not "GNU/Linux ARM." On the other hand, it references GCC 3.2, so I'm not sure how up-to-date the list is. I haven't found a gdb binary for this target that was built by CrossTool, though there are some gdb-6.4 files and headers. I googled several old posts about adding gdb support to CrossTool, but no clear docs. Regardless of whether GCJ supports this platform, I'd appreciate any guidance on building/getting a gdb I can use. Thanks in advance, Jay -------- Jay H. Hartley, Ph.D. Senior Software Engineer/Architect Modius, Inc.
