These are the packages that would be merged, in order: [ebuild N ] cross-mips64el-unknown-linux-gnu/binutils-2.19.50.0.1 USE="multitarget nls -multislot -test -vanilla" 0 kB [1] * package cross-mips64el-unknown-linux-gnu/binutils-2.19.50.0.1 NOT merged * * Detected file collision(s): * * /home/galaxy/gentoo/usr/share/locale/vi/LC_MESSAGES/opcodes.mo * /home/galaxy/gentoo/usr/share/locale/vi/LC_MESSAGES/gprof.mo * /home/galaxy/gentoo/usr/share/locale/vi/LC_MESSAGES/bfd.mo * /home/galaxy/gentoo/usr/share/locale/vi/LC_MESSAGES/ld.mo * /home/galaxy/gentoo/usr/share/locale/vi/LC_MESSAGES/binutils.mo * /home/galaxy/gentoo/usr/share/locale/nl/LC_MESSAGES/opcodes.mo * /home/galaxy/gentoo/usr/share/locale/nl/LC_MESSAGES/gprof.mo * /home/galaxy/gentoo/usr/share/locale/es/LC_MESSAGES/gas.mo * /home/galaxy/gentoo/usr/share/locale/es/LC_MESSAGES/opcodes.mo ... ... ... ... ... ... * /home/galaxy/gentoo/usr/share/locale/zh_TW/LC_MESSAGES/ld.mo * /home/galaxy/gentoo/usr/share/locale/zh_TW/LC_MESSAGES/binutils.mo
ah, that's probably due to USE=nls. @Mike: how about something like this: Index: toolchain-binutils.eclass =================================================================== --- toolchain-binutils.eclass (revision 36993) +++ toolchain-binutils.eclass (working copy) @@ -377,6 +377,10 @@ docinto opcodes dodoc opcodes/ChangeLog* fi + # Remove translations if this is cross, will collide with installed binutils + if is_cross ; then + rm -Rf "${ED}"/usr/share/locale + fi # Punt all the fun stuff if user doesn't want it :) has noinfo ${FEATURES} && rm -r "${ED}"/${DATAPATH}/info has noman ${FEATURES} && rm -r "${ED}"/${DATAPATH}/man
umm, no ... translations are installed wrong on your system for some reason. look at how it's done in linux: $ qlist -e sys-devel/binutils-2.19 | grep mo /usr/share/binutils-data/x86_64-pc-linux-gnu/2.19/locale/de/LC_MESSAGES/gprof.mo /usr/share/binutils-data/x86_64-pc-linux-gnu/2.19/locale/de/LC_MESSAGES/opcodes.mo /usr/share/binutils-data/x86_64-pc-linux-gnu/2.19/locale/es/LC_MESSAGES/gprof.mo /usr/share/binutils-data/x86_64-pc-linux-gnu/2.19/locale/es/LC_MESSAGES/bfd.mo /usr/share/binutils-data/x86_64-pc-linux-gnu/2.19/locale/es/LC_MESSAGES/opcodes.mo /usr/share/binutils-data/x86_64-pc-linux-gnu/2.19/locale/es/LC_MESSAGES/binutils.mo /usr/share/binutils-data/x86_64-pc-linux-gnu/2.19/locale/es/LC_MESSAGES/gas.mo /usr/share/binutils-data/x86_64-pc-linux-gnu/2.19/locale/es/LC_MESSAGES/ld.mo /usr/share/binutils-data/x86_64-pc-linux-gnu/2.19/locale/ru/LC_MESSAGES/binutils.mo
Just have seen that some binutils ebuilds in Prefix lack calling tc-binutils_apply_patches after tc-binutils_unpack. IMO this is the reason for wrongly installed locales. It's only binutils-2.16.1-r3.ebuild still calling tc-binutils_apply_patches. When additional patches can be applied _after_ tc-binutils_apply_patches, why don't we call toolchain-binutils_src_unpack instead of tc-binutils_unpack like in binutils-2.18-r4.ebuild?
All binutils ebuilds call toolchain-binutils_src-unpack(), so patches are applied. Something else must be going on. binutils for me seems to install these .mo files into a versioned location. It's unclear to me why DATAPATH isn't respected in this case.
