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