This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: GCJ 3.4 + MingW = Trouble
- From: "Ranjit Mathew" <rmathew4lists at hotmail dot com>
- To: <gnustuff at thisiscool dot com>,"GCJ Java" <java at gcc dot gnu dot org>
- Date: Tue, 6 May 2003 13:19:01 +0530
- Subject: Re: GCJ 3.4 + MingW = Trouble
- References: <A83VRPRNVR07GBKH7664XU08IMHMJG.3eb75ca9@p733>
- Reply-to: "Ranjit Mathew" <rmathew at hotmail dot com>
> Has anyone attempted to build GCC/GCJ 3.4 under MingW? I have been
I will, once the weekly snapshots switch over to the 3.4
branch/HEAD. (And once I finish "Golden Sun" on my GameBoy
Advance. ~sheepish grin~)
In general, you can expect the 3.4 code to be a bit
unstable, and perhaps broken, compared to 3.3 because this
is where people are trying out their new and cool stuff.
BTW, do you see any improvements (or otherwise) in build times?
> I am only attempting the cross build now. When I build the cross
> compiler and use it to generate a Win32 executable for a simple
> HelloWorld program, the generated program crashes with a segmentation
> violation. At first blush, this doesn't appear to be the same issue
Are you talking of a GCJ compiled "HelloWorld" (in Java) or one
written in C/C++?
> I don't know what flags to use to build a gdb-debuggable compiler (naive
> attempts to replace -g0 -O2 with -g2 -O0 and remove the -s flag in Ranjit's
> build scripts gave me libgcj link-time errors with multiply defined symbols),
> so I've resorted to peppering the code with printfs.
This is because methods marked "inline" are not really inlined
on MinGW until compiled with -O2 - on Linux, they are emitted as
weak symbols and therefore do not result in such errors with the
linker.
Such inline methods are to be found in the gjch generated
headers for java.lang.String, etc.
Ranjit.