>>> Installing (1 of 1) sys-devel/dummy-2 * checking 3 files for package collisions >>> Merging sys-devel/dummy-2 to / --- /Library/Gentoo/usr/ --- /Library/Gentoo/usr/lib/ >>> /Library/Gentoo/usr/lib/libdummy.1.0.dylib >>> /Library/Gentoo/usr/lib/libdummy.1.dylib >>> /Library/Gentoo/usr/lib/libdummy.dylib >>> needed obj /Library/Gentoo/usr/lib/libdummy.0.dylib >>> Safely unmerging already-installed instance... No package files given... Grabbing a set. --- replaced obj /Library/Gentoo/usr/lib/libdummy.dylib --- replaced obj /Library/Gentoo/usr/lib/libdummy.0.dylib <<< obj /Library/Gentoo/usr/lib/libdummy.0.1.dylib --- replaced dir /Library/Gentoo/usr/lib --- replaced dir /Library/Gentoo/usr >>> Original instance of package unmerged safely. >>> sys-devel/dummy-2 merged. <<< !needed obj /Library/Gentoo/usr/lib/libdummy.0.dylib >>> Auto-cleaning packages... For some reason, Portage thinks there is no consumer for libdummy.0, while it preserves it for this reason initially
This sounds interesting: I've fixed preserve-libs for AIX recently (you might have found the patch already for inclusion), where I've seen similar behaviour (for quite some time already): For the archive library containing the shared object, that shared object was not seen as consumer, so the archive was removed (including the shared object). While the problem was in the XCOFF-impl only, I've wondered why this did work before.
things changed there, and it is very well possible your patch (I haven't looked at it yet) can immediately be applied to MachO and PeCoff implementations
turned out to be a merge error here. scanmacho output was interpreted as ELF output, leading to an invalid arch being set (first 3 chars were missing, so _64 iso x86_64), the rest is just a chain of "not found" Fixed in 2.2.01.19295
committed