Michael Mohr wrote:
On Wed, 24 May 2006 10:26:05 -0700
David Daney <[EMAIL PROTECTED]> 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
