Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 642574 - amd64/17.1 profile: /lib/ needed by some binary packages
Summary: amd64/17.1 profile: /lib/ needed by some binary packages
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Profiles (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux bug wranglers
Depends on:
Blocks: no-symlink-lib
  Show dependency tree
Reported: 2017-12-28 22:42 UTC by Martin Väth
Modified: 2018-01-08 07:25 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
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- 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/

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-, a solution is
ln -s ../lib64/ /lib/

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 archtester Gentoo Infrastructure gentoo-dev Security 2018-01-03 23:36:11 UTC
Comment 4 Martin Väth 2018-01-04 08:49:24 UTC

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