Summary: | 'eselect compiler update' overwrites /usr/bin/run-java-tool | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | foo banana <videoscreen> |
Component: | [OLD] Unspecified | Assignee: | Kevin F. Quinn (RETIRED) <kevquinn> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | bug.hunter, eradicator, federico, java, toolchain |
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | output of emerge --info |
Description
foo banana
2006-07-10 13:35:46 UTC
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... |