Created attachment 376406 [details] emerge --info For firefox v28 & v29, revdev-rebuild notes the following files and then triggers a rebuild without the issue being solved: * Checking dynamic linking consistency [ 47% ] * broken /usr/lib64/firefox/browser/components/libbrowsercomps.so (requires libmozalloc.so libxul.so) * broken /usr/lib64/firefox/components/libdbusservice.so (requires libmozalloc.so libxul.so) * broken /usr/lib64/firefox/components/libmozgnome.so (requires libmozalloc.so libxul.so) * broken /usr/lib64/firefox/plugin-container (requires libxul.so) It'd appear the ebuilds aren't feeding the locations of these in the way portage would expect, or at least not buying it dinner first so the linkage is getting confused, and hence rebuilding what's there. Adding /usr/lib64/firefox into /etc/ld.so.conf and running ldconfig allows them to be found, and then revdep-rebuild runs with no errors/rebuilding -- and of course ld.so.conf gets rebuilt on every env-update.
The correct solution would be to have revdep-rebuild just ignore them, adding the path to ld.so.conf is not needed.
Created attachment 376616 [details] emerge --info
Comment on attachment 376616 [details] emerge --info I can confirm this and it's very annoying as it always asks for firefox to be rebuilt which is time consuming if you forget to cancel it or don't notice it.
(In reply to Jory A. Pratt from comment #1) > The correct solution would be to have revdep-rebuild just ignore them, > adding the path to ld.so.conf is not needed. The specific fix may be above my pay grade and expertise, or what is exactly going wrong -- and it may be I don't understand something the firefox ebuild is doing right that revdep should ignore... but isn't revdep-rebuild having a problem because the linkage is confused? eg, after editing ld.so.conf the libs are showing up (whereas they don't before) with ldconfig -v: /usr/lib64/firefox: libmozsqlite3.so -> libmozsqlite3.so libmozalloc.so -> libmozalloc.so libxul.so -> libxul.so Which goes away after any env update. If the ebuild and all is as it should be, is there some large whitelist of other problem applications ignored by revdep? If firefox is added or one is created to ignore it, wouldn't you be creating a situation where real problems aren't seen? Either way, it isn't a trivial compile, firefox is up there with the largest builds in the tree and are frequently used, so I'd imagine this is hitting a lot of people even if they haven't realized it yet (unless using revdep has drastically fallen out of use?)
(In reply to drunkenbatman from comment #4) > (In reply to Jory A. Pratt from comment #1) > > The correct solution would be to have revdep-rebuild just ignore them, > > adding the path to ld.so.conf is not needed. > > The specific fix may be above my pay grade and expertise, or what is exactly > going wrong -- and it may be I don't understand something the firefox ebuild > is doing right that revdep should ignore... but isn't revdep-rebuild having > a problem because the linkage is confused? eg, after editing ld.so.conf the > libs are showing up (whereas they don't before) with ldconfig -v: > > /usr/lib64/firefox: > libmozsqlite3.so -> libmozsqlite3.so > libmozalloc.so -> libmozalloc.so > libxul.so -> libxul.so > > Which goes away after any env update. If the ebuild and all is as it should > be, is there some large whitelist of other problem applications ignored by > revdep? If firefox is added or one is created to ignore it, wouldn't you be > creating a situation where real problems aren't seen? > > Either way, it isn't a trivial compile, firefox is up there with the largest > builds in the tree and are frequently used, so I'd imagine this is hitting a > lot of people even if they haven't realized it yet (unless using revdep has > drastically fallen out of use?) 29.0.1 has just been added to tree, it addresses the issue. firefox calls run-mozilla.sh whichs sets up the path so it finds it own libs. This is why we can safely ignore the failure that revdep-rebuild is showing. It comes down to not using rpath any longer. After updating if you can still duplicate please reopen.
> 29.0.1 has just been added to tree, it addresses the issue. firefox calls > run-mozilla.sh whichs sets up the path so it finds it own libs. This is why > we can safely ignore the failure that revdep-rebuild is showing. It comes > down to not using rpath any longer. After updating if you can still > duplicate please reopen. Thanks! Emerged & ran rev-dep and it didn't pop up so it looks like whatever ld_library_path magic is being used is now a-OK. *gives the horns*
I've seen that the solution has been to include /usr/lib64/firefox in the SEARCH_DIRS_MASK. I don't think that's the correct solution, as now revdep-rebuild doesn't detect when firefox is broken. For example I've upgraded the package dev-libs/icu, revdep-rebuild didn't say anything about rebuilding firefox, but firefox was failing to start. It was hard to realize that revdep-rebuild is not working for firefox as a result of the change.
