Bug 642574 – amd64/17.1 profile: /lib/ld-linux-x86-64.so.2 needed by some binary packages

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Martin Väth 2017-12-28 22:42:00 UTC]

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?)

[Comment 1 Alexander Tsoy 2017-12-28 23:54:45 UTC]

(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"

:)

[Comment 2 Martin Väth 2017-12-29 08:57:06 UTC]

(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.

[Comment 3 Michał Górny 2018-01-03 23:36:11 UTC]

PEBKAC.

[Comment 4 Martin Väth 2018-01-04 08:49:24 UTC]

> 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.

[Comment 5 Ulenrich 2018-01-08 00:46:25 UTC]

This hotfix action solved my problem

cd /opt/googleearch && \
 patchelf --set-interpreter /lib64/ld-linux-x86-64.so.2 googleearth-bin

[Comment 6 Martin Väth 2018-01-08 07:25:12 UTC]

> 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.)