gcj-mingw32: it compiles, it runs, it segfaults
Adam Megacz
adam@megacz.com
Mon Dec 10 20:55:00 GMT 2001
Well, I've gotten a lot done today... I've gotten the mingw32 support
back in a state where the compiler builds and generates
soundly-linking static binaries. Sadly, they crash all over the place.
$ gdb --nw hello.exe
GNU gdb 5.0 (20010428-1)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) run
Starting program: /cygdrive/z/hello.exe
abnormal program termination
Program exited with code 03.
(gdb) trace
trace command requires an argument
(gdb) bt
No stack.
I don't know enough about the innards of gcj or the code it generates
to make much sense of this... can anybody help me out here? My best
guess is that something's up with jvgenmain... I noticed that after
doing a "make install", no jvgenmain binary wound up in my install
area. Does gcj have an internal copy of jvgenmain?
I'm also running with no-threads... perhaps that has something to do
with it?
I tried creating my own main with jvgenmain, but I get this when
linking it:
/tmp/ccs1iKap.o: In function `main':
/home/megacz/hello-main.cc(.text+0x3e): undefined reference to `_JvRunMain(java::lang::Class*, int, char const**)'
Despite the fact that
megacz@curry$/usr/local/cross-gcc/bin/i686-pc-mingw32-nm --extern-only /usr/local/cross-gcc/i686-pc-mingw32/lib/libgcj.a | grep JvRunMain
000015f0 T _JvRunMain
Urgh...
- a
More information about the Java
mailing list