[gentoo-dev] Re: RFC: c++14 global USE flag

[Duncan <1i5t5.duncan@cox.net>]

Diego Elio Pettenò posted on Sun, 26 Apr 2015 17:41:04 +0100 as excerpted:

> On 25 April 2015 at 16:57, Duncan <1i5t5.duncan@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