I've recently been doing some "spring cleaning" (or messing about, as it's more often called) and have updated my Java version to 1.4.2.10 from 1.4.2.09. I've also upgraded to GCC 3.4 and done the emerge -e system | world rebuild. I also recently upgraded to the 2.6.14 kernel version. Not all at once, but over a week or two. Now....

My system boots correctly, behaves correctly and seems generally fine. Java also works in general (I can load eclipse and work on projects, as far as I can tell). However, I can't build eclipse-sdk any more; on closer inspection I can't seem to build anything using ant. A simple failure case is a bare emerge jakarta-regexp which tries to build jakarta-regexp-1.3-r2 which gets as far as the initial class build and then causes a JVM crash. The crash message is :

Now, I've been searching like a mad ferret to find out what's going on and the similar cases (i.e. not libzip.so but other native libraries) on the Gentoo forums were resolved by a sun-jdk rebuild combined with using java-config to make sure the version is correct. Needless to say, I've tried this. The other avenue was on Sun's development boards where it was suggested that this can be caused by certain bundled native libraries (in this case libzip.so) not being binary compatible with certain libraries they depend upon (please excuse my vagueness, I don't understand the situation fully).

So, has anyone got any idea what's happening? Also, I can't seem to revert to sun-jdk-1.4.2.9 as the ebuild seems to have been removed on an emerge sync. How do I revert to a minor revision after I've updated to a new one?

Hope you can help guys, thanks in advance,

Mike

Last edited by BeepCleep on Tue Jan 17, 2006 3:12 pm; edited 1 time in total

Hope this sheds some light. I've seen this thing before when I was doing JNI stuff on Win32 but that's to be expected. Never had a VM crash on Linux (let alone Gentoo) before now. Such are the consequences of binary installs

Seems like the fix suggested requires the JVM linux source code, a patch and a build. Seeing as the source build of Java doesn't exist anymore (as an ebuild, AFAIK), to get 1.4.2.10 working, I'll have to manually compile and then copy across / symlink the libzip.so that's created.
Or, I could revert to 1.4.2.09; the ebuild for this has disappeared so would it be a good enough temporary fix to get the 1.4.2.09 installer, rename it to 1.4.2.10 and then re-run the 1.4.2.10 emerge? Of can I get the old 1.4.2.09 ebuild from somewhere?

Right, option 2 looks like it won't work. I've since tried the current 1.4 version of IBM-JDK and Blackdown (and, yes, using java-config -S) and am getting exactly the same problem suggesting that an external library is to blame. In addition, the source build of the JDK seems to be off the menu too as it requires a specific older version of GCC which I am unable (at present) and unwilling (due to the complexity I believe it will involve) to install. So, I'm a bit stuck. I've tried emerging the libstdc++-v3 compatibility library and re-emerging zlib but to no avail; at this rate I'm going to have to work in Windows because I need a correctly working JVM. I hope some of you have some good suggestions....

I've now tried to use sun-jdk-1.5 and it gives, surprise surprise, the same problem. I'm getting increasingly annoyed by this as it's clearly something I've done in my kernel (although my old kernel, which worked a while back, has the same problem), glibc or zlib. Any ideas on what I can, should try next (I've even done an emerge -e world in desperation)?

P.S. I have posted the error to the offical Sun bug report area but they've got a lead time of roughly 3 weeks atm.

I've managed to resolve the issue. The emerge -e world (my extreme last resort) didn't work because it was using, to some extent, ant to build ant and it's dependencies. The "fix" was to for all ant's dependencies to rebuild with jikes (which does not have the native issues of javac) and then rebuild ant again with javac. This seems to have solved this very strange issue. I believe an emerge -C <java_dependent_package> and then an emerge <java_dependent_package> will end up having the same effect. Changing the JDK installed will NOT help as I believe the problem is an incompatibility with previously built jar files and native zip library; you need to completely rebuild the java toolchain to resolve this issue. Anyway, I hope this proves of use...

Can you recall how exactly you did this? If I emerge jikes java-config doesn't give me the ability to set jikes as system VM. I have the same problem that you had, very annoying. _________________"You may say I'm a dreamer, but I'm not the only one."

It seems like I solved this issue by using sun-jdk-1.4* instead of blackdown - for some reasons with the sun jdk I could compile ant-core, but not with blackdown. In the ant-dependancy tree, ant-core was before any packages providing a "jikes"-flag, so that couldn't help.
This applies to a brand new gentoo install, the problem occurd at "emerge wildfire", which has ant as dependency, and it was the first emerge of any jdk in the lifetime of that install, so it's impossible that any old files lying around cause this._________________"You may say I'm a dreamer, but I'm not the only one."