This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: FYI: Article "Building GCJ on Windows" Relocated
- From: Ranjit Mathew <rmathew at gmail dot com>
- To: TEIXOEIRA at terra dot es
- Cc: GCJ <java at gcc dot gnu dot org>
- Date: Fri, 21 Apr 2006 15:03:41 +0530
- Subject: Re: FYI: Article "Building GCJ on Windows" Relocated
- Openpgp: url=http://rmathew.com/aa_6C114B8F.txt
- References: <28140093.1145467225361.JavaMail.root@cps2> <44477FD8.3000701@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ranjit Mathew wrote:
>
> "/home/ranmath/tmp/mingw/i686-pc-mingw32/libjava/classpath/lib"
> does have java.lang.Object, but it indeed does not have the
> attribute "gnu.gcj.gcj-compiled" (as shown by jcf-dump), even
> though the java.lang.Object built for i686-pc-linux-gnu
> using the same GCC sources does have this attribute. For some
> reason, the Linux->MinGW cross-compiler is not producing this
> attribute. I haven't investigated this problem much, but I don't
> understand why this should be the case.
This was because the Classpath configure script was not
finding GCJ (since GCJ for the target was named i686-pc-mingw32-gcj)
and was picking up "javac" from Sun's JDK instead. I resolved
this by using "--with-gcj=$TARGET-gcj" for the configuration.
So one needs to add "--with-sysroot=$PREFIX --with-gcj=$TARGET-gcj"
to the configure options used in "cfgwingcc.sh" and also
extract "mingw-runtime" to the "$WINGCC_DIR/mingw" folder
instead of the "$WINGCC_DIR/$TARGET" folder as I mention
in my article. I would update my article and scripts with
this information.
That's not the end of my woes though - the crossed-native
GCC that is built by this process does not seem to be
as relocatable as it used to be when run on a Windows box.
For example, "gcc" is not able to find C runtime headers (!)
and I have to rename the "mingw" folder back to "i686-pc-mingw32"
to make it work! "gcc" is not able to spawn "as" from binutils
to assemble the generated files even though it is in the
same "bin" folder as the "gcc" binary. *This used to work
before* and is supposed to work. :-(
The only saving grace is that GCJ is able to create
.class files (but not object files, since it uses the
same driver as the rest of the GCC) and "gij" is able
to run interpreted programmes. So at least "libgcj.jar"
is located properly when the toolchain is relocated.
Uggghhh!
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://rmathew.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFESKb1Yb1hx2wRS48RAlG0AJ4ipMitktWzjsZH2w3ckC8jVxjHnACfVoqp
uRBPNWGvZL5FOUSyNzyTdD8=
=Pvpo
-----END PGP SIGNATURE-----