gandalf ~ # revdep-rebuild --library '/usr/lib64/liblzma.so.0' * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries using /usr/lib64/liblzma.so.0 * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Checking dynamic linking [ 100% ] * There are no dynamic links to /usr/lib64/liblzma.so.0... All done. gandalf ~ # rm '/usr/lib64/liblzma.so.0' gandalf ~ # revdep-rebuild * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 2% ] * broken /lib64/libarchive.so.2.7.1 (requires liblzma.so.0) [ 81% ] * broken /usr/lib64/R/lib/libR.so (requires liblzma.so.0) Reproducible: Always
The problem is that revdep-rebuild called with --library '/usr/lib64/liblzma.so.0' will not find things that are linked against /usr/lib/liblzma.so.0 even though this is a symlink to the same library.
To find all broken links against the library, revdep-rebuild should be invoked with the command 'revdep-rebuild --library liblzma.so.0' However, revdep-rebuild is supposed to work with full paths to find binaries that are linked to the library at that specific path. Since that is failing to work, we have a bug there that needs to be fixed.
Further investigation shows that revdep-rebuild is working exactly as designed. The full path support to the --library option is find binaries that link against the library in that specific path. Since in this case, the binaries are linking to the symlink /usr/lib instead of /usr/lib64, it is failing to find them which is how it was designed to work. vapier: Do you have any thoughts on how we want to handle this, since even though it is working as designed, it is not working as desired? This is related to bug 339134, where revdep-rebuild was finding undesired libraries in the emulation packages.
Maybe the solution would be to change preserve_old_lib_notify so that it echos the call to revdep-rebuild without the full path, but includes the full path when echoing the rm call?
*** Bug 357679 has been marked as a duplicate of this bug. ***
The more I think about it, the more I think that the solution is to do the following: 1. Revert the commit in revision 1.352 to the eutils eclass. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/eutils.eclass?r1=1.351&r2=1.352 2. Reopen Bug 339134 3. For the emulation packages that install binary libraries, modify the ebuilds to include a file with an appropriate SEARCH_DIRS_MASK entry in /etc/revdep-rebuild. I'm not comfortable with touching the eutils eclass by myself. So do we need to discuss this on gentoo-dev or what?
*** Bug 357907 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > The more I think about it, the more I think that the solution is to do the > following: > > 1. Revert the commit in revision 1.352 to the eutils eclass. > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/eutils.eclass?r1=1.351&r2=1.352 > > 2. Reopen Bug 339134 > > 3. For the emulation packages that install binary libraries, modify the ebuilds > to include a file with an appropriate SEARCH_DIRS_MASK entry in > /etc/revdep-rebuild. > > I'm not comfortable with touching the eutils eclass by myself. So do we need to > discuss this on gentoo-dev or what? base-system@g.o is the maintainer for eutils.eclass so adding to CC list. in particular vapier might have something to say on this...
i changed the suggested revdep-rebuild output only because people complained. i dont particularly care what it reads. i guess running `readlink -f` on the paths from ldd wouldnt help ?
(In reply to comment #9) > i guess running `readlink -f` on the paths from ldd wouldnt help ? Or maybe even `readlink -m`? It would have to do the same to the full-path --library argument as well.
you cant mung the argument to --library since it may be a regexp
*** Bug 358889 has been marked as a duplicate of this bug. ***
I got bit pretty bad by this one, when following eutils suggestions and deleted the libmpfr that gcc was still linked to. When your only compiler won't run, Gentoo is not happy about finding ways out.... I guess my point is that I think this can be a fairly serious problem. Could an additional flag to revdep-rebuild get added that has it run `find -L / -samefile ${lib}` for each regex result? (Forgive my ignorance about how revdep-rebuild handles the regex --library args.)
i could change baselayout to write 04multilib with the symlinked paths last. i cant think of that causing problems for people. $ ldd /usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.2/cc1 | grep /usr libmpc.so.2 => /usr/lib64/libmpc.so.2 (0x00007f1aad4c3000) libmpfr.so.4 => /usr/lib64/libmpfr.so.4 (0x00007f1aad270000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x0000003012c00000)
I've tested revdep-rebuild with 04multilib modified and it returns the correct results. I'm still looking at modifying revdep-rebuild to use readlink -f on the returned results from ldd, but it is not a trivial change to the code.
ive changed multilib.eclass now http://sources.gentoo.org/eclass/multilib.eclass?r1=1.84&r2=1.85 if no one complains, i'll put out baselayout updates so people automatically pick up this change. they're both due for new versions anyways.
*** Bug 361551 has been marked as a duplicate of this bug. ***
*** Bug 465642 has been marked as a duplicate of this bug. ***
*** Bug 382589 has been marked as a duplicate of this bug. ***
