I've bitten by this too... the problem is that portage does not follow a particular order when rebuilding subslot deps, so when upgrading dev-libs/libffi (in this case from 0/7 to 0/8) it can schedule lots of other packages between when the new libffi is installed and when python is rebuilt. If portage is interrupted for any reason during this period, you're screwed.
To recover, I followed these steps: 1. temporarily bring back /usr/lib/libffi.so.7 (/usr/lib64/libffi.so.7 if you're on amd64) from whatever source you can find (backup, saved binpkg, livecd/usb). You will need to copy both the actual library (libffi.so.7.x.y) and the versioned symlink (libffi.so.7 -> libffi.so.7.x.y); make sure you do not touch the existing libffi.so -> libffi.so.8.z.w symlink 2. re-emerge your main python version (the one you use to run portage, see emerge --info) 3. finish your upgrade 4. remove the files you copied in 1 5. do a revdep-rebuild pass, just in case I would not call installing dev-libs/libffi-compat a solution -- you still need a working python to do that, and it won't protect you from future breakage like this.
This may help: https://wiki.gentoo.org/wiki/Project:Portage/Fixing_broken_portage
It will not help in this case, since what's broken is python and not portage.
If that won't work for whatever reason, chroot into your system after you boot with the latest Live-USB and try to update @system. Alternatively, reinstall.
Neither will this, as you won't be able to execute python (i.e. run portage) inside the chroot. HTH andrea
