After switching to the 17.1 profile, some binary packages won't start. In my case, it is sci-geosciences/googleearth-7.1.8.3036 which dies with the confusing message ./googleearth: 43: ./googleearth: ./googleearth-bin: not found As I eventually found, the actual reason is that the googleearth-bin has hard-coded the path /lib/ld-linux-x86-64.so.2 I am aware that googleearth is currently not in the gentoo tree (but cf. bug 642334), but independent of that it is probably not good if binary packages won't start: If I understood correctly, the main motivation for the move is to _improve_ such compatibility, not to prevent it. In case of googlearth-7.1.8.3036, a solution is ln -s ../lib64/ld-linux-x86-64.so.2 /lib/ld-linux-x86-64.so.2 So I think it would make sense to include this symlink into some package (glibc?)
(In reply to Martin Väth from comment #0) > I am aware that googleearth is currently not in the gentoo tree (but cf. bug > 642334)... From the ebuild provided in that bug report: patchelf --set-interpreter /lib/ld-linux$(usex amd64 "-x86-64" "").so.2 ${PN}-bin || die "patchelf failed" :)
(In reply to Alexander Tsoy from comment #1) > From the ebuild provided in that bug report: Ouch! I had not checked the ebuild since I did not expect that the binary is actually patched by the ebuild. In fact, the old ebuild from the gentoo repository (from which my version had been installed) did the same wrong patching. When patching in the correct way, there is no problem, of course. So perhaps this bug report is INVALID or actually only a report for an ebuild which is (currently) not in the tree. I am not sure whether I should mark the bug as solved (INVALID?) and/or change the title to refer to googleearth, only: Contrary to my original expectation, so far I did not run into another binary with the same problem. In any case, I will comment on the other bug.
PEBKAC.
> PEBKAC An offence which was as unnecessary as wrong (as the real problem was a bug in an ebuild which only by accident was recently removed from the tree for completely different reasons). Your aggressive behaviour had already previously prevented me from contributing more to gentoo. I was just about to consider whether I should give it a new try and proxy-maintain googleearth. Thanks for the reminder that I will not.
This hotfix action solved my problem cd /opt/googleearch && \ patchelf --set-interpreter /lib64/ld-linux-x86-64.so.2 googleearth-bin
> This hotfix action solved my problem Yes: Just the patching (with patchelf) should already have been done right (with /$(get_libdir) instead of /lib) in the ebuild. The original ebuild just did it wrong (and this ebuild had been essentially copied to the bug cited above). The ebuilds in the bug (and in the mv overlay) are fixed meanwhile, so if googleearth should be reintroduced to the tree it will presumably work fine. The treecleaned ebuild cannot be fixed, of course. One of the cases where treecleaning was harmful since people do not necesarily want to remove treecleaned packages from their system. (And ignoring of dynamics deps now heavily encourages them in this, but this is a different story.)
