What I did was this helix ~ # crossdev -t mips64-octeon-linux-gnu helix ~ # crossdev -C mips64-octeon-linux-gnu * Uninstalling target 'mips64-octeon-linux-gnu' ... cross-mips64-octeon-linux-gnu/binutils: 2.23.1 none none cross-mips64-octeon-linux-gnu/gcc: 4.7.2-r1 none none cross-mips64-octeon-linux-gnu/glibc: 2.17 none none cross-mips64-octeon-linux-gnu/linux-headers: 3.8 none none All selected packages: cross-mips64-octeon-linux-gnu/glibc-2.17 cross-mips64-octeon-linux-gnu/linux-headers-3.8 cross-mips64-octeon-linux-gnu/binutils-2.23.1 cross-mips64-octeon-linux-gnu/gcc-4.7.2-r1 >>> Unmerging (1 of 4) cross-mips64-octeon-linux-gnu/binutils-2.23.1... >>> Unmerging (2 of 4) cross-mips64-octeon-linux-gnu/gcc-4.7.2-r1... >>> Unmerging (3 of 4) cross-mips64-octeon-linux-gnu/glibc-2.17... >>> Unmerging (4 of 4) cross-mips64-octeon-linux-gnu/linux-headers-3.8... /usr/mips64-octeon-linux-gnu: directory still exists; remove recursively? [y/N] y but then i realized that it did not remove everything helix ~ # ls -la /usr/bin/|grep octeon lrwxrwxrwx 1 root root 50 Apr 27 12:51 mips-octeon-linux-gnu-addr2line -> /usr/libexec/gcc/mips64-octeon-linux-gnu/addr2line lrwxrwxrwx 1 root root 43 Apr 27 12:51 mips-octeon-linux-gnu-ar -> /usr/libexec/gcc/mips64-octeon-linux-gnu/ar lrwxrwxrwx 1 root root 43 Apr 27 12:51 mips-octeon-linux-gnu-as -> /usr/libexec/gcc/mips64-octeon-linux-gnu/as lrwxrwxrwx 1 root root 48 Apr 27 12:51 mips-octeon-linux-gnu-c++filt -> /usr/libexec/gcc/mips64-octeon-linux-gnu/c++filt lrwxrwxrwx 1 root root 48 Apr 27 12:51 mips-octeon-linux-gnu-elfedit -> /usr/libexec/gcc/mips64-octeon-linux-gnu/elfedit lrwxrwxrwx 1 root root 46 Apr 27 12:51 mips-octeon-linux-gnu-gprof -> /usr/libexec/gcc/mips64-octeon-linux-gnu/gprof lrwxrwxrwx 1 root root 43 Apr 27 12:51 mips-octeon-linux-gnu-ld -> /usr/libexec/gcc/mips64-octeon-linux-gnu/ld lrwxrwxrwx 1 root root 47 Apr 27 12:51 mips-octeon-linux-gnu-ld.bfd -> /usr/libexec/gcc/mips64-octeon-linux-gnu/ld.bfd lrwxrwxrwx 1 root root 43 Apr 27 12:51 mips-octeon-linux-gnu-nm -> /usr/libexec/gcc/mips64-octeon-linux-gnu/nm lrwxrwxrwx 1 root root 48 Apr 27 12:51 mips-octeon-linux-gnu-objcopy -> /usr/libexec/gcc/mips64-octeon-linux-gnu/objcopy lrwxrwxrwx 1 root root 48 Apr 27 12:51 mips-octeon-linux-gnu-objdump -> /usr/libexec/gcc/mips64-octeon-linux-gnu/objdump lrwxrwxrwx 1 root root 47 Apr 27 12:51 mips-octeon-linux-gnu-ranlib -> /usr/libexec/gcc/mips64-octeon-linux-gnu/ranlib lrwxrwxrwx 1 root root 48 Apr 27 12:51 mips-octeon-linux-gnu-readelf -> /usr/libexec/gcc/mips64-octeon-linux-gnu/readelf lrwxrwxrwx 1 root root 45 Apr 27 12:51 mips-octeon-linux-gnu-size -> /usr/libexec/gcc/mips64-octeon-linux-gnu/size lrwxrwxrwx 1 root root 48 Apr 27 12:51 mips-octeon-linux-gnu-strings -> /usr/libexec/gcc/mips64-octeon-linux-gnu/strings lrwxrwxrwx 1 root root 46 Apr 27 12:51 mips-octeon-linux-gnu-strip -> /usr/libexec/gcc/mips64-octeon-linux-gnu/strip lrwxrwxrwx 1 root root 48 Apr 27 12:51 mips64-octeon-linux-gnu-elfedit -> /usr/libexec/gcc/mips64-octeon-linux-gnu/elfedit -rwxr-xr-x 1 root root 10456 Apr 27 12:56 mips64-octeon-linux-gnu-gcc-ar -rwxr-xr-x 1 root root 10456 Apr 27 12:56 mips64-octeon-linux-gnu-gcc-nm -rwxr-xr-x 1 root root 10456 Apr 27 12:56 mips64-octeon-linux-gnu-gcc-ranlib lrwxrwxrwx 1 root root 47 Apr 27 12:51 mips64-octeon-linux-gnu-ld.bfd -> /usr/libexec/gcc/mips64-octeon-linux-gnu/ld.bfd I believe crossdev -C should remove these as well.
hmm, what version of binutils-config are you using ? seems to me that binutils symlinks in /usr/bin/ and /usr/libexec/gcc/ are getting cleaned up. my test: crossdev -s0 mips64-octeon-linux-gnu crossdev -C mips64-octeon-linux-gnu i don't have anything left in /usr/bin/
I used 3-r3. If you say that it works for you I can try to reproduce it again. It may be possible the crossdev -t mips64-octeon-linux-gnu step did not succeed and then I tried to remove using crossdev -C whatever was already installed. I will try again.
(In reply to comment #2) crossdev doesn't really matter here. as long as binutils itself finishes installing, it should uninstall itself cleanly.
Some updates today I built a new mips64-unknown-linux-gnu like this: crossdev -t mips64-unknown-linux-gnu I notice that a mips-* appeared in /usr/bin along with the mips64-* expected one... I've no idea why. lrwxrwxrwx 1 root root 51 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-addr2line -> /usr/libexec/gcc/mips64-unknown-linux-gnu/addr2line lrwxrwxrwx 1 root root 44 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-ar -> /usr/libexec/gcc/mips64-unknown-linux-gnu/ar lrwxrwxrwx 1 root root 44 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-as -> /usr/libexec/gcc/mips64-unknown-linux-gnu/as lrwxrwxrwx 1 root root 49 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-c++filt -> /usr/libexec/gcc/mips64-unknown-linux-gnu/c++filt lrwxrwxrwx 1 root root 49 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-elfedit -> /usr/libexec/gcc/mips64-unknown-linux-gnu/elfedit lrwxrwxrwx 1 root root 47 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-gprof -> /usr/libexec/gcc/mips64-unknown-linux-gnu/gprof lrwxrwxrwx 1 root root 44 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-ld -> /usr/libexec/gcc/mips64-unknown-linux-gnu/ld lrwxrwxrwx 1 root root 48 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-ld.bfd -> /usr/libexec/gcc/mips64-unknown-linux-gnu/ld.bfd lrwxrwxrwx 1 root root 44 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-nm -> /usr/libexec/gcc/mips64-unknown-linux-gnu/nm lrwxrwxrwx 1 root root 49 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-objcopy -> /usr/libexec/gcc/mips64-unknown-linux-gnu/objcopy lrwxrwxrwx 1 root root 49 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-objdump -> /usr/libexec/gcc/mips64-unknown-linux-gnu/objdump lrwxrwxrwx 1 root root 48 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-ranlib -> /usr/libexec/gcc/mips64-unknown-linux-gnu/ranlib lrwxrwxrwx 1 root root 49 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-readelf -> /usr/libexec/gcc/mips64-unknown-linux-gnu/readelf lrwxrwxrwx 1 root root 46 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-size -> /usr/libexec/gcc/mips64-unknown-linux-gnu/size lrwxrwxrwx 1 root root 49 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-strings -> /usr/libexec/gcc/mips64-unknown-linux-gnu/strings lrwxrwxrwx 1 root root 47 Jun 8 23:07 /usr/bin/mips-unknown-linux-gnu-strip -> /usr/libexec/gcc/mips64-unknown-linux-gnu/strip Is this expected? having mips-* along with mips64-* could be a bit confusing if you only requested a 64-bit toolchain (even though mips is a symlink to mips64) Then I removed it like this but I still see mip64-* toolchain components in /usr/bin helix ~ # crossdev -C mips64-unknown-linux-gnu * Uninstalling target 'mips64-unknown-linux-gnu' ... cross-mips64-unknown-linux-gnu/binutils: 2.23.1 none none cross-mips64-unknown-linux-gnu/gcc: 4.7.3 none none cross-mips64-unknown-linux-gnu/glibc: 2.17 none none cross-mips64-unknown-linux-gnu/linux-headers: 3.9 none none All selected packages: cross-mips64-unknown-linux-gnu/linux-headers-3.9 cross-mips64-unknown-linux-gnu/glibc-2.17 cross-mips64-unknown-linux-gnu/gcc-4.7.3 cross-mips64-unknown-linux-gnu/binutils-2.23.1 >>> Unmerging (1 of 4) cross-mips64-unknown-linux-gnu/binutils-2.23.1... >>> Unmerging (2 of 4) cross-mips64-unknown-linux-gnu/gcc-4.7.3... >>> Unmerging (3 of 4) cross-mips64-unknown-linux-gnu/glibc-2.17... >>> Unmerging (4 of 4) cross-mips64-unknown-linux-gnu/linux-headers-3.9... /usr/mips64-unknown-linux-gnu: directory still exists; remove recursively? [y/N] y helix ~ # ls -la /usr/bin/|grep mips lrwxrwxrwx 1 root root 51 Jun 8 23:07 mips-unknown-linux-gnu-addr2line -> /usr/libexec/gcc/mips64-unknown-linux-gnu/addr2line lrwxrwxrwx 1 root root 44 Jun 8 23:07 mips-unknown-linux-gnu-ar -> /usr/libexec/gcc/mips64-unknown-linux-gnu/ar lrwxrwxrwx 1 root root 44 Jun 8 23:07 mips-unknown-linux-gnu-as -> /usr/libexec/gcc/mips64-unknown-linux-gnu/as lrwxrwxrwx 1 root root 49 Jun 8 23:07 mips-unknown-linux-gnu-c++filt -> /usr/libexec/gcc/mips64-unknown-linux-gnu/c++filt lrwxrwxrwx 1 root root 49 Jun 8 23:07 mips-unknown-linux-gnu-elfedit -> /usr/libexec/gcc/mips64-unknown-linux-gnu/elfedit lrwxrwxrwx 1 root root 47 Jun 8 23:07 mips-unknown-linux-gnu-gprof -> /usr/libexec/gcc/mips64-unknown-linux-gnu/gprof lrwxrwxrwx 1 root root 44 Jun 8 23:07 mips-unknown-linux-gnu-ld -> /usr/libexec/gcc/mips64-unknown-linux-gnu/ld lrwxrwxrwx 1 root root 48 Jun 8 23:07 mips-unknown-linux-gnu-ld.bfd -> /usr/libexec/gcc/mips64-unknown-linux-gnu/ld.bfd lrwxrwxrwx 1 root root 44 Jun 8 23:07 mips-unknown-linux-gnu-nm -> /usr/libexec/gcc/mips64-unknown-linux-gnu/nm lrwxrwxrwx 1 root root 49 Jun 8 23:07 mips-unknown-linux-gnu-objcopy -> /usr/libexec/gcc/mips64-unknown-linux-gnu/objcopy lrwxrwxrwx 1 root root 49 Jun 8 23:07 mips-unknown-linux-gnu-objdump -> /usr/libexec/gcc/mips64-unknown-linux-gnu/objdump lrwxrwxrwx 1 root root 48 Jun 8 23:07 mips-unknown-linux-gnu-ranlib -> /usr/libexec/gcc/mips64-unknown-linux-gnu/ranlib lrwxrwxrwx 1 root root 49 Jun 8 23:07 mips-unknown-linux-gnu-readelf -> /usr/libexec/gcc/mips64-unknown-linux-gnu/readelf lrwxrwxrwx 1 root root 46 Jun 8 23:07 mips-unknown-linux-gnu-size -> /usr/libexec/gcc/mips64-unknown-linux-gnu/size lrwxrwxrwx 1 root root 49 Jun 8 23:07 mips-unknown-linux-gnu-strings -> /usr/libexec/gcc/mips64-unknown-linux-gnu/strings lrwxrwxrwx 1 root root 47 Jun 8 23:07 mips-unknown-linux-gnu-strip -> /usr/libexec/gcc/mips64-unknown-linux-gnu/strip lrwxrwxrwx 1 root root 49 Jun 8 23:07 mips64-unknown-linux-gnu-elfedit -> /usr/libexec/gcc/mips64-unknown-linux-gnu/elfedit -rwxr-xr-x 1 root root 10456 Jun 8 23:26 mips64-unknown-linux-gnu-gcc-ar -rwxr-xr-x 1 root root 10456 Jun 8 23:26 mips64-unknown-linux-gnu-gcc-nm -rwxr-xr-x 1 root root 10456 Jun 8 23:26 mips64-unknown-linux-gnu-gcc-ranlib lrwxrwxrwx 1 root root 48 Jun 8 23:07 mips64-unknown-linux-gnu-ld.bfd -> /usr/libexec/gcc/mips64-unknown-linux-gnu/ld.bfd
(In reply to Markos Chandras from comment #4) yes. the FAKE_TARGET stuff is known to not get cleaned up. i wonder if that stuff is even really useful and maybe we should just punt it entirely.
i'm going to punt FAKE_TARGETS support from binutils as i think we've outlived it at this point. gcc supports biarch for mips/powerpc/s390/sparc and has for a while now (w/sparc being the last one with gcc-4.4). if the kernel doesn't build anymore, then we should spend cycles getting that fixed rather than continuing with this prefix hack.
i've cut binutils-config-4 now w/FAKE_TARGETS dropped. it was added like 10 years ago, so i think it's safe to say it's past its prime ;).
http://sources.gentoo.org/eclass/toolchain-binutils.eclass?r1=1.133&r2=1.134
