Recently, I upgraded my JDK from sun-jdk-1.4.1.02 to sun-jdk-1.4.1.03 as part of a routine update. This caused the following problems. (1) Browser plugin in /usr/lib/nsbrowser/plugins was not updated and so referred to sun-jdk-1.4.1.02. The ebuild gave message below. * Not creating symlink for the java plugin, because there already is a java plugin installed. This meant that the plugin was referring to sun-jdk-1.4.1.02 (which had been removed) rather than the new package sun-jdk-1.4.1.03. (2) The system lost java command capability on the console as the system VM was set to sun-jdk-1.4.1.02 which had been removed. (3) The sun-jdk-1.4.1.03 package is compiled using gcc3 and does not work with mozilla-firebird-bin. The browser recognises it as 1.4.1_02-b06 rather than 1.4.1_03-b02 as it should do and as mozilla nightly does correctly. (4) No mention was made in the postinst of the ebuild that the browser plugin and java-config settings were now referring to an obselete JDK and that one should update their settings. Here are some proposed changes. (1) All java ebuilds add to postinst einfo/ewarn messages such as below. * If this is an upgrade of your JRE/JDK and * this is set as your default java VM then * please run java-config to reassign your VM. * If your java browser plugin is dependent on this package * then please revise your plugin location. (2) Greater automation could be adopted although my guess is that the user base will be divided on their opinions on this subject. A simple check by every JRE/JDK ebuild could be made to see if it is the current system VM and if it is it could use java-config to reassign system VM to the new package as last step. The user VM would be left untouched. Or it could simply spit out the command to reassign system VM as an einfo message. (3) Some policy should be decided about what plugin symlinks are made to /usr/lib/nsbrowser/plugins. Are gcc3 plugins to be added or only gcc2 plugins to save breaking compatibility with browsers? The answer to this depends on your default browser. firebird-bin = gcc2 firebird-cvs & firebird = gcc3 mozilla = gcc3 Often I have wished that there were different plugin directories for gcc2 and gcc3. The argument against creating two different plugin directories is of course that sometime in the future firebird-bin will be built with gcc3 whereas right now the maintainer is using redhat 7.3 with gcc2. Such a wait is generally unpleasant and it is much easier to make changes on the user end. As is evident, there are many issues which require thought here and both JRE/JDK ebuilds and the java-config script must share the load of dealing with these issues. If java-config is further refined to take account of changing VM's on the fly and of browser plugins then the ebuild can simply use that functionality. This bug can serve as a focal point for change and contribution on this topic and it has been made a normal bug rather than an enhancement since some things are incorrect in their current state.
To extend change (3) a little more: One can have a plugin directory for binaries in for example /opt/plugins and another for source packages in say /usr/lib/plugins and the browsers can simply symlink to these depending on whether they are binaries or source packages. To add another proposed change about creating new browser plugins when upgrading J packages: (4) A check can be made if the current java plugin symlink refers to package being unmerged and rather than leaving it there one can remove it and add a new one from new package. I agree this is taking a considerable amount of liberty but certainly omitting new plugins on the basis that there are old and obselete plugins in the plugin directory is surely not suitable either. If this change was not being made then a message about it would be useful too.
This is hairy; (1) Yes, the ebuild should know that if it's an upgrade of itself the plugin should be symlinked forcibly (2) Are you sure this is the case after running env-update or logging in again? (3) The present upstream maintainer of the mozilla-firebird binary builds at mozilla.org is using RedHat 7.3 and doesn't appreciate that GCC 3 is what is used by a massive number of users now. I'm trying to have him create a GCC 3 build.
In reply to your question, there may be no point in running env-update surely as the jdk that the default system VM referred to has now been removed. When I reset the system vm to the new jdk and sourced profile all was well.
I can make a patch for the upgrade to not break, but for now it need to set the system vm to the latest JDK JRE installed. I know its not the better solution for this but it can fix a lot of problems. What you think about it ? In java.eclass: java_pkg_postinst() { - if [ -z `java-config --java 2> /dev/null` ] ; then - einfo "No default VM found, setting ${VMHANDLE} as default" + einfo "Setting ${VMHANDLE} as default" + einfo "Use java-config to reassign your VM." java-config --set-system-vm=${VMHANDLE} + /usr/sbin/env-update + source /etc/profile - fi }
*** Bug 17881 has been marked as a duplicate of this bug. ***
Yes. That sounds good. I'm also glad it applies the settings in the current terminal rather an outputting a message about sourcing /etc/profile. But when you say the latest jdk do you mean the highest version or the most recently emerged jdk?
The most recently VM emerged its going to be set as the system default, cause i cant find a way to make comment #0 point 2.
*** Bug 30577 has been marked as a duplicate of this bug. ***
Setting the system-vm to the latest emerged version is not a very good idea. On My system, I've got both jdk-1.4 and jdk-1.5 installed. Jdk-1.5 however breaks a few packages (because of the 'enum' keyword) and is not ready for production use. I only use it for my personal projects. But with the current behaviour the ebuild keeps setting it to the system default vm after an upgrade, and I have to keep setting it back to 1.4. It even causes compilation failures when doing an 'emerge -Du world'. I think it should only set the default vm when the newly installed version is an upgrade of the installed version. That means, it has to be the same package and the same slot.
java guys what's the word on this bug it's 3+ months old. I just started running into it myself. --------------------------------------------------------------------------------- LoadPlugin: failed to initialize shared library (m[/opt/blackdown-jdk-1.4.1_beta/jre/plugin/i386/mozilla/javaplugin_oji.so: undefined symbol: SetGlobalServiceManager__16nsServiceManagerPP17nsIServiceManager] --------------------------------------------------------------------------------- This causes my freshly compiled mozilla to crash and burn at what seems to be about every 3-4th webpage I visit which causes me to be less productive which then results in less things getting fixed for gentoo users as a whole. Downgrading mozilla is not an option either (GLSA-200409-26) I'm looking for a definitive solution to this problem rather quickly so I can be productive again. thanks in advance.
Thinking we should 1) force installation of the plugin and 2) change the plugin along with java-config --set-system-vm any comments/objections?
Well considering my mozilla has crashed about 40 from the time I last commented on this bug, I'm game and object nothing that gets me back to a state that's functional.
Whatever you think best. I've no objections. I wanted to make bugzilla aware of the problem.
i don't use mozilla, and absolutely hate applets so i want to make sure i don't make it worse
One of the biggest problems is blackdown-jdk seems to download binaries compiled with gcc 2.95.3, even though there should be logic in the ebuild to determine the proper version to fetch. This is probably what's crashing mozilla.
there aren't any blackdown-jdk's in the tree any more that install a 2.95, and i tested it, that doesn't cauz mozilla to crash (for me at least) solar why are you still using blackdown-jdk-1.4.1_beta? that was removed from the tree 17months ago the way plugins are installed atm is incosisent and can leave symlinks around that should be removed, i'm attempting to clean it up but lots jdk/jre's in the tree
hrmm 17 months. Clearly you can tell I like updating java :) I'll attempt to update right now and hope that it resolves the problem and report back (success/failures)
Created attachment 40229 [details, diff] big-jre-jdk-plugin-cleanup.diff since this (sorta majorly) changes the eclass i would like some ppl to test & comment if i'm not being a dumbass
and a typo in the first few lines of that patch :X (no, i didn't test _every_ ebuild yet, gonna do that when/if i commit)
Updated java. orig problem with unfedined references to symbol names appears to have gone away. End result of mozilla still crashing is the same on anything java related. "libgnomevfs-WARNING **: Unable to create ~/.gnome directory: Bad address" and I've updated just about everything else in the chain. Thanks for your help but I'm now thinking the bug lies elsewhere with the above. I'll test your patches in about another 17 months :)
this patch won't fix your problem anyway, it's basicly just a cleanup, so that last merged jre/jdk is always the plugin in use, and that it doesn't install 2 java plugins(like it would in same cases b4) and made the ibm's check for gcc version too when installing the plugin
in the tree
