Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: RFC: c++14 global USE flag
Date: Tue, 28 Apr 2015 19:34:37
Message-Id: pan$d9003$7badbf5a$bdf0d464$9159dbcd@cox.net
In Reply to: Re: [gentoo-dev] Re: RFC: c++14 global USE flag by "Diego Elio Pettenò"
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

Replies

Subject Author
Re: [gentoo-dev] Re: RFC: c++14 global USE flag "Anthony G. Basile" <blueness@g.o>