Diego Elio Pettenò posted on Sun, 26 Apr 2015 17:41:04 +0100 as excerpted:
> On 25 April 2015 at 16:57, Duncan <1i5t5.dun...@cox.net> wrote: > >> Of course, one thing that could make the process faster would be if C++ >> based packages were marked some way. > > > revdep-rebuild --soname 'libstdc\+\+.so.*' > > should do the trick. Stuff that does not link the library (statically > linked or using libsupc++) should not really matter. Thanks. Obvious in hindsight. =:^) Answering my own toolchain question then, for folks using portage as PM... [wow, portage takes /awhile/ evaluating order!]... Looks like dev-libs/gmp could be a problem. Back in the day we didn't have it to worry about, but coreutils uses it with USE=gmp, which I'd guess quite a few folks would have set for multi-processing support. But gmp appears to have a C and a C++ lib (libgmpxx.so.*), and coreutils wasn't in the above list on its own, so it would appear to be fine even if libgmpxx.so.* is broken, so... But obviously worth testing before each new gcc compatibility bump gets unmasked... Other than gmp, it looks like the old rules still apply just fine. Upgrade gcc, gcc-config switch to the new version, and emerge --emptytree @world, or at least revdep-rebuild --soname 'libstdc\+\+.so.*' as Diego points out. And as I already said, with modern hardware that takes... a morning... well, maybe a day if you've lots of packages installed or are on a slow (if modern) machine, not the two days plus it used to take when that was simply accepted as the way it was. So shouldn't be a big deal. Other than the usual upgrade bugs, then, the problem should be pretty well restricted to servantware which can't be rebuilt; more specifically, to C++ using servantware that can't be rebuilt. And that has always been a problem, which the people choosing to use it have chosen to live with, but which shouldn't hold back the free world that has chosen not to live in such bondage. For these people, what? Of course they used to get along when gcc's C++ was unstable before, so I guess they still can. Does libstdc++ get builtin as static? If so it shouldn't be an issue. If not... I guess they can preload libstdc++ from an older gcc. So maybe a news item explaining both the gcc upgrade procedure, and how to preload an old libstdc++, if they need to for binary-only servantware or whatever. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
