!!! existing preserved libs: >>> package: dev-libs/icu-4.0.1 * - /usr/lib/libicuuc.so.38 * - /usr/lib/libicuuc.so.38.1 * used by /opt/googleearth/libevll.so (x11-misc/googleearth-5.0.11337.1968_beta) Googleearth provides its own copy of libicuuc.so in its own directory, as /opt/googleearth/libicuuc.so.38 , so there should be no need to preserve this lib system-wide for googleearth. Is there some kind of automatic lib preservation exclusion mechanism, like CONFIG_PROTECT_MASK for config files, so that packages can declare directories that shouldn't be checked?
It's a flaw in the algorithm that decides what to preserve. There's no reason ebuilds should have to be aware of it. As a workaround, you can manually remove the preserved library.
Actually, ldd reports that it links to /usr/lib/libicuuc.so.38.1, so I'm not quite sure how we're going to handle this. However, googleearth still appears to run if I move /usr/lib/libicuuc.so.38.1 to a temporary location, and lsof reports that "/opt/googleearth/libicuuc.so.38" is mapped into memory when googleearth is running. In this case, ldd reports "libicuuc.so.38 => not found". The RPATH doesn't provide a clue, since `scanelf -r /opt/googleearth/libevll.so` simply reports of bunch of paths that don't exist.
(In reply to comment #1) > There's no reason ebuilds should have to be aware of it. I was quite surprised when you wrote this. Seems there is no magic way out. (In reply to comment #2) > Actually, ldd reports that it links to /usr/lib/libicuuc.so.38.1, To reproduce the environment as the googleearth wrapper script sets it up: $ cd /opt/googleearth $ LD_LIBRARY_PATH=. ldd libevll.so > so I'm not quite sure how we're going to handle this. I notice that for files like ./libminizip.so, the above is even different from a simple LD_LIBRARY_PATH=/opt/googleearth in some other working directory. For portage to reproduce this, it would need to know working directory and LD_LIBRARY_PATH modification. It would be easier to simply mask the whole googleeath package from library preservation, and rely on the dependencies stated in the ebuild to take care of everything.
there's no real way to push LD_LIBRARY_PATH hacks up into portage (nor do i think we should) if the binary had RPATH of like $ORIGIN/../lib/, then it'd probably "just work" without any wrapper script
An idea that's also a hack but perhaps smaller - just check if the supposedly needed preserved file is part of the package itself? And maybe restrict that check to /opt only? Not sure how much is that tailored to this particular case, or how generally useful it could be, though.
I havn't looked into the logic that decides what to preserve, but I see two problems. 1) ldd reports things like "./libIGCore.so => not found". This can be solved by running ldd in the directory containing the lib. It then reports "./libIGCore.so (0xf77f4000)" 2) Portage needs to handle "./<library>"-cases correctly.
(In reply to comment #4) > there's no real way to push LD_LIBRARY_PATH hacks up into portage (nor do i > think we should) I agree. > if the binary had RPATH of like $ORIGIN/../lib/, then it'd probably "just > work" without any wrapper script Google Earth is closed source, so setting RPATH using linker flags is not an option. Should the googleearth ebuild use app-admin/chrpath to change the rpath of the binary before installing it? And if that works, get rid of the wrapper? (In reply to comment #5) > An idea that's also a hack but perhaps smaller - just check if the supposedly > needed preserved file is part of the package itself? You mean check by base name only, ignoring the directory? Hackish indeed, but sounds sensible nevertheless.
*** This bug has been marked as a duplicate of bug 215242 ***
(In reply to comment #7) > Google Earth is closed source, so setting RPATH using linker flags is not an > option. Should the googleearth ebuild use app-admin/chrpath to change the > rpath of the binary before installing it? And if that works, get rid of the > wrapper? That chrpath approach seems like an excellent solution.
Considering that chrpath can potentially bug used to fix this bug, it is much different from the case(s) described in bug #215242.
I've tried adding a line like this to googleearth-6.2.1.6014-r1.ebuild: chrpath -r /opt/googleearth ${PN}-bin gpsbabel *.so *.so.* || die And it fails with the following error: googleearth-bin: no rpath or runpath tag found. gpsbabel: no rpath or runpath tag found. libalchemyext.so: no rpath or runpath tag found. libapiloader.so: no rpath or runpath tag found. libauth.so: no rpath or runpath tag found. libbase.so: no rpath or runpath tag found. libbasicingest.so: no rpath or runpath tag found. libcollada.so: no rpath or runpath tag found. libcommon_gui.so: no rpath or runpath tag found. libcommon_platform.so: no rpath or runpath tag found. libcommon.so: no rpath or runpath tag found. libcommon_webbrowser.so: no rpath or runpath tag found. libcomponentframework.so: no rpath or runpath tag found. libevll.so: no rpath or runpath tag found. [SNIP]
This seems to set the RPATH correctly: # Set RPATH for preserve-libs handling (bug #265372). local x for x in ${PN}-bin gpsbabel *.so *.so.* ; do patchelf --set-rpath /opt/${PN} ${x} || \ die "patchelf failed on ${x}" done However, scanelf no longer works with the binaries after they've been patched like this (tested with pax-utils-0.3.0 and 0.4). It just exits successfully and doesn't produce any output. The output of ldd shows it properly resolving the libraries in /opt/googleearth though, and googleearth appears to run correctly. @vapier: Do you want a separate bug report for this scanelf issue?
(In reply to comment #12) > However, scanelf no longer works with the binaries after they've been > patched like this (tested with pax-utils-0.3.0 and 0.4). It just exits > successfully and doesn't produce any output. The output of ldd shows it > properly resolving the libraries in /opt/googleearth though, and googleearth > appears to run correctly. > > @vapier: Do you want a separate bug report for this scanelf issue? Nevermind the above. It didn't work because I was using scanelf -qf instead of -qF. I was also confused by missing /var/db/pkg/sci-geosciences/googleearth-6.2.1.6014-r1/NEEDED{,.ELF.2} files, but that was due to the ebuild setting RESTRICT=binchecks, which causes portage to skip the scanelf call.
So, in summary, the solution that I would suggest for this sort of issue is to adjust the RPATH with patchelf --set-rpath, so that preserve-libs can properly resolve the library dependencies. Also, we might want to reconsider the use of RESTRICT=binchecks in googleearth-6.2.1.6014-r1.ebuild, since that prevents portage from generating the NEEDED.ELF.2 file that is required for FEATURES=preserve-libs to operate.
(In reply to comment #14) > Also, we might want to reconsider the use of RESTRICT=binchecks in > googleearth-6.2.1.6014-r1.ebuild, since that prevents portage from > generating the NEEDED.ELF.2 file that is required for FEATURES=preserve-libs > to operate. I've fixed portage to generate NEEDED.ELF.2 regardless of RESTRICT=binchecks, and to trigger a QA Notice if RESTRICT=binchecks is used and ELF files are installed: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=61571e4e8ee3f4f999782c542b4be84d8be8c729 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=72314d2e24aa96af614b052b8b29e6d02d37a641
@caster: Any objection to adding something like this to src_prepare for all googleearth ebuilds? # Set RPATH for preserve-libs handling (bug #265372). local x for x in ${PN}-bin gpsbabel *.so *.so.* ; do patchelf --set-rpath /opt/${PN} ${x} || \ die "patchelf failed on ${x}" done
For testing, I've added the following code to googleearth-6.2.2.6613.ebuild: # Set RPATH for preserve-libs handling (bug #265372). local x for x in * ; do # Use \x7fELF header to separate ELF executables and libraries [[ -f ${x} && $(od -t x1 -N 4 "${x}") == *"7f 45 4c 46"* ]] || continue patchelf --set-rpath '$ORIGIN' "${x}" || \ die "patchelf failed on ${x}" done If there are no complains, we can go ahead and backport this to the older ebuilds.
(In reply to comment #17) > For testing, I've added the following code to googleearth-6.2.2.6613.ebuild: > > # Set RPATH for preserve-libs handling (bug #265372). > local x > for x in * ; do > # Use \x7fELF header to separate ELF executables and libraries > [[ -f ${x} && $(od -t x1 -N 4 "${x}") == *"7f 45 4c 46"* ]] || continue > patchelf --set-rpath '$ORIGIN' "${x}" || \ > die "patchelf failed on ${x}" > done > > If there are no complains, we can go ahead and backport this to the older > ebuilds. Sure, thanks for the solution! Just leave this open so I can remove the launcher script later, at least on versions where I don't patch it to workaround a locale bug.
(In reply to comment #18) > Just leave this open so I can remove the launcher script later, at least on > versions where I don't patch it to workaround a locale bug. Okay, reassigned.
