serial comm. with rxtx, GPSExplorer, and GCJ -- runtime exception

Wed May 24 23:05:00 GMT 2006

Michael Mohr wrote:
> On 2006年5月24日 10:26:05 -0700
> David Daney <ddaney@avtrex.com> wrote:
>>>>Michael Mohr wrote:
>>>>>Hello,
>>>>>>I'm currently attempting to use GCC 4.1's gcj to compile a medium-sized (6000-line) java application. Unfortunately, it requires raw access to serial ports, as implemented by RXTX. It appears that RXTX has already been modified to compile using CNI; however, the port appears to be in early alpha stage.
>>>>>>I am able to compile RXTX (mostly) without complaint. I am also able to compile my application -- GPSExplorer -- with no warnings or errors using GCC 4.1. However, it exits when run with the following exception:
>>>>>>Exception in thread "main" java.lang.UnsupportedOperationException
>>> at gnu.java.awt.peer.gtk.GdkGraphicsEnvironment.getAllFonts (lib-gnu-java-awt-peer-gtk.so)
>>> at GPSExplorer.<init> (GPSExplorer)
>>> at GPSExplorer.main (GPSExplorer)
>>>>>>>Looks like GraphicsEnvironment.getAllFonts() is not supported by your 
>>libgcj.
>>> Okay. Is there a person who I could contact that is working on related classes? I'd be happy to lend a hand, at least in regards to implementing functions missing from my own application.
>
The classpath project is the source of the culpable code. See 
http://www.gnu.org/software/classpath/
>>>>The program makes use of the AWT and Swing classes. It runs perfectly under any JVM after 1.2 (and probably before, but I haven't tested that far back). I compile and link GPSExplorer as follows:
>>>>>>rm -f *.o *.s GPSExplorer
>>>>>>for x in *.java
>>>do
>>> gcj -classpath .:$PWD/RXTX/RXTX.jar -c $x
>>>done
>>>>>>gcj *.o -L$PWD/RXTX -lrxtx -o GPSExplorer --main=GPSExplorer
>>>>>>As I see it, there are 3 possibilities:
>>> o Something is wrong with the app in question, GPSExplorer
>>>>Perhaps.
>>>>>>> o Something went wrong with the CNI RXTX port
>>>>Again, perhaps, but that is not the problem you are seeing.
>>>>>>> o Something isn't right with GCJ
>>>>>>>Yeah. The AWT support is not complete yet.
>>> I figured that, but I didn't want to seem pretentious by stating that there was a problem with GCJ. There may still be problems with GPSExplorer under GCJ, but as of yet this is the most visible issue. Incidentally, why was I able to compile and link GPSExplorer if a used function was not available?

Many methods are stubbed out so that you don't get compile time errors. 
 That this is a good thing is up for debate.
>>>>>>>The text of the error leads me to Door #3, but I could be very wrong. This is my first attempt to compile a large Java application using GCJ.
>>>>>>Here's the output of gcc -v:
>>>Using built-in specs.
>>>Target: i686-pc-linux-gnu
>>>Configured with: /var/tmp/portage/gcc-4.1.0-r1/work/gcc-4.1.0/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.0 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --enable-java-awt=gtk --enable-languages=c,c++,java,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
>>>Thread model: posix
>>>gcc version 4.1.0 (Gentoo 4.1.0-r1)
>>>>>>When I enable -Wall, I get hundreds of warnings, all of which are either:
>>> o warning: Discouraged redundant use of 'public' modifier in declaration of abstract method 
>>> o warning: An empty declaration is a deprecated feature that should not be used.
>>>>>>Other than those two errors, nothing is reported. This is the contents of GPSExplorermain.i after the final link with -save-temps:
>>>>>>>Then don't enable -Wall.
>>> I'm perfectly aware that I can choose not to enable -Wall. I was following precisely the directions given for filing a bug report, which state at http://gcc.gnu.org/bugs.html :
>> "Before reporting that GCC compiles your code incorrectly, please compile it with gcc -Wall and see whether this shows anything wrong with your code that could be the cause instead of a bug in GCC."
>> I wanted it to be clear that I had read the directions and was following procedure.
>
Right, good point.
David Daney