So I finally got some time to hack some Classpath code again this bank holiday weekend, and ended up feeling like I got nowhere, running into bugs and annoying problems at each turn.

Me and JikesRVM are still fighting; I haven’t had a successful build as yet. After working round the apt problem (by moving the offending files out the way and commenting out the build rule, hehe), I proceeded to watch it download ecj (after having ignored my native version earlier). This ran into problems, which I later found were down to my own stupidity. I hadn’t installed the optional ant tasks as required. That fixed, I ran into a fun issue with its Classpath download. It decided to try and ungzip it twice, so tar complained and stopped the build. Something is being clever along the way and decompressing the gzip before it reaches tar I guess.

That fixed (by again hacking the build files), I realised that the file Ian kindly gave me (the one generated by the apt tool) had got mangled in downloading. Leastways, it didn’t look like any Java file I’d ever seen before. To cap it all, I then updated and that broke the build even earlier. Hopefully, that will be fixed soon.

Returning to Classpath itself, I noticed that the Mauve runs were coming up with a ridiculous number of errors, so decided to investigate. Updating, I found I couldn’t even build. The new gtkpeer.c file wonderfully assumes that the system is 32-bit. Good job I have -Werror on or I would be experiencing some nice random segfaults next time I use the GUI stuff. A couple of #ifdefs later and it was fixed.

I then proceeding to uncover the root of the test problems — there had to be some common problem, given that it was a fairly mixed bunch of tests. Turns out the build was no longer including the locale information. I’m quite amazed no-one had spotted this earlier. It was soon fixed by correcting the new find invocation in lib/

So all in all, didn’t get very far but at least thinks seem to work again…