Did my usual morning "emerge -uavDN world" 2 days ago. It always recommends that I run "emerge --depclean" afterward, and I usually don't, because I like keeping 3 kernels in /boot. But I figured - what the heck; I never recompile any of the previous kernels, so go ahead - it is cleaning the source, not my binaries in /boot. So I ran it. Looks like one thing it got rid of was an older version of binutils, but not sure.
Then I realized that I was using gentoo-sources-4.9.6-r1 still; I'd never compiled and 4.9.16 and installed it. Also I still had like 5 directories in /usr/src, so I did a rm -fr /usr/src/linux-4.4.* and, like usual when I' removing older kernels, did rm -fr /lib/modules/4.4.*, and rm /boot/config-4.4.* (I save copies of my configs too) and rm /boot/kernel-4.4.*
Copied the .conf into /usr/src/linux-4.9.16-gentoo/, changed the symlink, cd into it, and tried to run "make oldconfig"
Error #1: an error about not finding libopcodes-2.25.1.so; yep - The whole directory for it did not exist; I assume depclean removed it.
Not sure what was up with that, so went to a backup (about 2 weeks old) and copied the whole /usr/lib/binutils/i686-pc-linux-gnu/2.25.1 directory. Tried again.
Error #2 (current): /usr/lib/gcc/i686-pc-linux-gnu/4.9.4/../../../../i686-pc-linux-gnu/bin/as: error while loading shared libraries: libopcodes-2.26.1.so: cannot open shared object file: No such file or directory
I check the 2.26.1 directory and - yep, there is no libopcodes in there. Nor in the backup from 2 weeks ago.
Checked "gcc-config -l", and only one (and it is selected): i686-pc-linux-gnu-4.9.4
Thinking it was a ld thing, I ran "ldconfig -v" - no change.
Any ideas on how to fix? I have a backup from 2 weekends ago available...
Last edited by pdr on Sat Apr 22, 2017 10:40 am, edited 1 time in total.
EMERGE_DEFAULT_OPTS="--buildpkg"
This will save your life more than once, at cost of some disk space (which on today's computers shouldn't really be a problem)
ps: for your problem i think jaglover already gave your the right answer.
No - make clean did nothing (and I did not expect it to; the assembler is trying to load a so that does not exist (libopcodes-2.26.1.so) (or, well, it is not in the directory where it is supposed to be)
libopcodes-2.26.1.so belongs to binutils-2.26.1. If that's not selected, select one you do have.
If binutils is missing, that's a verybadthing, you will need to install a binpackage from a BINHOST, then rebuild your own binutils.
--depclean should not have removed your only binutils, that would be a serious bug.
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
The only "official" (known to portage) binutils I have is 2.26.1. The issue is, there is no libopcode in there (including in my backup from 2 weeks ago). I copied the 2.25.1 from my backup, but it does not show up in eselect (don't know how those get "registered").
I can restore my full system backup, but I'm *really* trying avoid that as this SEEMS like it is a simple problem, that somehow it is trying to use 2.25.1 when it should be using all 2.26.1...
Get the binutils binary for your arch.
Put it into its place in /usr/portage/packages/ (you may not have that).
Get the Packages file from the top level directory of the binary tree on the binhost and put it into /usr/portage/packages/
That solved it. I thought the problem was "you are not supposed to be using libopcodes any more in 2.26.1", when - as you surmised - it was "where the heck did your libopcodes-2.26.1.so go???"