Am Mon, 22 May 2017 19:33:55 +0200 schrieb Jörg Schaible <joerg.schai...@gmx.de>:
> Peter Humphrey wrote: > > > On Monday 22 May 2017 09:49:01 Jörg Schaible wrote: > >> Hi Peter, > >> > >> Peter Humphrey wrote: > >> > >> [snip] > >> > [...] > >> > >> well, this does not seem to be the complete truth. When I switched > >> to gcc 5.x I did a revdep-rebuild for anything that was compiled > >> against libstdc++.so.6 just like the according news entry was > >> recommending. And I am quite sure that those Qt plugins were part > >> of my 515 recompiled packages. > >> > >> Nevertheless, my KDE 4 apps were broken after the update to Qt > >> 4.8.7. Rebuilding anything that was using libQtCore.so.4 solved > >> it, but I fail to see how this is related to the gcc update two > >> weeks ago. > > > > I can only suggest you read bug report 618922 if you haven't > > already, including following its reference to bug 595618. It makes > > sense to me. > > It does not for me. My packages were already compiled with gcc-5.4.0. > Those Buzilla issues only talk about (plasma/qt) packages compiled > with previous gcc-4.x which are supposed to be incompatible. All of > the plasma/qt related packages that have been recompiled, because > they were built upon libQtCore.so.4 were already recompiled with > gcc5. I've checked my logs. Is the problem maybe order of building packages? From your description I see one edge case: Plasma could have been compiled with gcc-5 but linked to qt still built with gcc-4. Then, qt was rebuilt after this and is compiled by gcc-5 now. Without reading the bug report I would guess that is what the bug is about: Linking plasma against gcc-4 built qt binaries... Even when you rebuild qt with gcc-5 after this, you'd need to relink plasma. From your logs, you should see the order in which those packages were rebuilt and linked. revdep-rebuild is not always able to perfectly order packages right for emerge, and emerge in turn has no problem with wrong ordering because it is rebuilding packages and the dependency constraints are already fulfilled (read: runtime and build deps are already there). Portage does not consider rebuilds as a hard dependency/precondition for rebuilding other packages... As far as I understood, "--changed-deps" should fix this and also rebuild packages depending on the rebuilt packages _after_ they've been rebuilt. The "--empty" option would have a similar effect, tho rebuild many more packages. You could've tried if "revdep-rebuild ... -- --changed-deps" would've done anything better. I would be interested... -- Regards, Kai Replies to list-only preferred.
