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/