This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: [gcj-eclipse-merge-branch] MinGW ecj: Cross-built ecjx?!
- From: Mohan Embar <gnustuff at thisiscool dot com>
- To: Adam Megacz <adam at megacz dot com>
- Cc: java at gcc dot gnu dot org
- Date: Tue, 05 Dec 2006 06:47:30 -0600
- Subject: Re: [gcj-eclipse-merge-branch] MinGW ecj: Cross-built ecjx?!
- Reply-to: gnustuff at thisiscool dot com
Hi Adam,
>http://gcc.gnu.org/ml/java-patches/2006-q4/msg00193.html
>http://gcc.gnu.org/ml/java-patches/2006-q4/msg00194.html
>http://gcc.gnu.org/ml/java-patches/2006-q4/msg00195.html
>http://gcc.gnu.org/ml/java-patches/2006-q4/msg00196.html
Nice work. I had identified these issues here:
http://gcc.gnu.org/ml/java/2006-12/msg00029.html
...but was holding off on submitting patches for these
because I wanted to understand the nature of ecj1/ecjx
better. Like your comment for gc-dbtool, I don't understand
why these Win32 executables are being by the cross build
and what purpose they serve at this stage in the game.
I'm also not seeing ecj.jar used for any purpose other
than to build Win32 executables, which leads me to wonder
if the i686-pc-mingw32-gcj cross has Java 5 functionality
or even works at all. Have you tried it? Maybe I'm missing
the boat entirely.
What's more, this (Makefile.am):
## Build an ecjx from a .jar.
ecjx_SOURCES =
## We use the BC ABI here so that we don't need to compile ecj.jar.
## Hopefully the user has compiled it into his system .db.
## However, even if not it will run reasonably quickly.
ecjx_LDFLAGS = -findirect-dispatch \
--main=org.eclipse.jdt.internal.compiler.batch.GCCMain \
-Djava.class.path=$(ECJ_JAR)
ecjx_LINK = $(GCJLINK)
ecjx_LDADD = -L$(here)/.libs libgcj.la
ecjx_DEPENDENCIES = libgcj.la libgcj.spec
...leads me to wonder whether this could even work for
static builds in the first place, given that even gij is
broken on Win32 due to the fact that it really needs to be
linked with the entirety of libgcj.a and not just whatever it
happens to see at the moment it's being statically linked.
Finally, for this:
http://gcc.gnu.org/ml/java-patches/2006-q4/msg00195.html
...don't forget that in addition to Andrew's comments requiring
the necessity of initializing and destroying these, you don't
need new type(defs) for park_mutex and park_cond and can
already use the existing _Jv_Mutex_t and _Jv_ConditionVariable_t
for these.
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/