I am running an ~x86 system, and I just followed the upgrade guide at http://www.gentoo.org/proj/en/java/java-upgrade.xml. here is the problem: when I execute java or javac, I get this error: $ java gcc-config error: java wrapper: Unable to determine executable. CTARGET=i686-pc-linux-gnu exec=java zsh: exit 1 java My java system is correctly updated: $ java-check-environment * === Java Environment Checker === * The purpose of this script is to check the sanity of your Java Environment. * We have significantly changed and improved the way Java is handled in many respects. * Please refer to http://www.gentoo.org/proj/en/java/java-upgrade.xml for details * Checking vm_environment_files ... [ ok ] * Checking user_settings ... * Running as root. Don't need to check user settings. [ ok ] * Checking generation_1_system_vm ... [ ok ] * Java environment is sane. Congratulations! $ java-config-1 -L [sun-jdk-1.4.2.12] "Sun JDK 1.4.2.12" (/etc/env.d/java/20sun-jdk-1.4.2.12) * $ java-config-2 -L 1) Sun JDK 1.4.2.12 [sun-jdk-1.4] (/usr/share/java-config-2/vm/sun-jdk-1.4) *) Sun JDK 1.5.0.07 [sun-jdk-1.5] (/usr/share/java-config-2/vm/sun-jdk-1.5) This problem manifest itself the first time I ran java-1.5-fixer in the upgrade guide
java, javac, etc point to /usr/bin/run-java-tool. This is normally this is a bash script provided by java-config-2. On the user's system, that file is an elf binary. I suspect maybe gcc-config or something is overwritting the file somehow. Adding toolchain peeps for input.
The problem is a wierd interaction between eselect compiler and java-config-2 $ emerge =java-config-2* fixes the problem. /usr/bin/run-java-tool is a bash script. now run $ eselect compiler update /usr/bin/run-java-tool is now an elf binary. repeat ad nauseum.
Created attachment 91398 [details] output of emerge --info
I'm having this problem too Re-emerge java-config-2 (temporarily) solved the problem
Could someone that can reproduce the problem attach a log with the output of: # strace eselect compiler update (You may need to emerge strace first) This should help track down which file (/usr/bin/java, /usr/bin/javac, etc) is being replaced, and by extension /usr/bin/run-java-tool.
Some analysis: gcc installs /usr/<ctarget>/gcc-bin/<version>/{rmic,rmiregistry} "eselect compiler update" installs wrappers for these into /usr/bin. It does this because it installs wrappers in /usr/bin for all binaries in /usr/<ctarget>/gcc-bin/<version> and /usr/<ctarget>/bin (where ctarget is something like i686-pc-linux-gnu). java-config-2 overwrites /usr/bin/{rmic,rmiregstry} with softlinks to /usr/bin/run-java-tool - I'll leave it to the java-config gurus to say what it's doing here. Running "eselect compiler update" causes those files to be replaced with wrappers - however because they're now softlinks to /usr/bin/run-java-tool that gets replaced instead. So we have a bit of a mess. We need to decide who really owns /usr/bin/{rmic,rmiregistry} - gcc (with eselect-compiler), or java-config-2, and one of them needs to avoid fiddling with them. I'm inclined to say java-config-2 shouldn't be wrapping gcc files, but that's just a first impression. Is java-config-2 supposed to be dealing with the gcc java support? [... time passes ...] Ahh; interesting. gcc-4.0.3 and gcc-4.1.1 have those executables renamed as grmic and grmiregistry, presumably to avoid that same naming conflict. So if you only have >=gcc-4 installed, the problem does not occur. Perhaps the simplest solution would be to rename those same executables on older compiler versions. Also, perhaps eselect-compiler could avoid copying to softlinks (e.g. by doing "rm D; cp S D" instead of "cp -f S D" for the short-cut names).
BTW for comparison, gcc+gcc-config installs /usr/bin wrappers only for {,<ctarget>-}{cpp,gcc,c++,g++,f77,g77,gcj}, (no gfortran, hmm) so doesn't trigger.
ok; I'll take this on. after discussion on IRC, plan is to alter the gcc-3 ebuilds to generate grmic/grmiregistry as the gcc-4 builds do, and to add a sanity check in eselect-compiler to prevent it overwriting symlinks that it doesn't expect. eradicator - shout if you don't want me to do that last bit. Just for the record, here's the NEWS text from gcc-4 on this same issue: * In order to prevent naming conflicts with other implementations of these tools, some GCJ binaries have been renamed: + rmic is now grmic, + rmiregistry is now grmiregistry, and + jar is now fastjar. In particular, these names were problematic for the jpackage.org packaging conventions which install symlinks in /usr/bin that point to the preferred versions of these tools. in gcc-3.4.6 jar is called gcj-jar; I'll check the older gcc versions for that as well.
I've just committed changes to the gcc-3.3* and gcc-3.4* ebuilds to rename those executables. The following script will do the same change on an already-built system, to save re-building gcc unnecessarily: ---- #!/bin/bash for bindir in /usr/*/gcc-bin/3.[34]*; do for exe in rmic rmiregistry; do [[ -f ${bindir}/${exe} ]] && echo mv ${bindir}/${exe} ${bindir}/g${exe} done done ---- obviously this will create collisions if you later re-emerge an already-emerged gcc.
So with those changes made, can we consider this bug resolved?
(In reply to comment #10) > So with those changes made, can we consider this bug resolved? From your point of view, yes. I'm keeping it open as I have an outstanding action from SpanKY to clean things up a bit (i.e. move the code from the ebuilds to toolchain.eclass) which I'll get to next week. Also outstanding are alterations to eselect-compiler to detect target softlinks.
ok; processing for rename of rmic/rmiregistry now moved to toolchain.eclass Only thing left is to deal with overwriting softlinks in eselect-compiler.
eselect-compiler is dead for now...
