From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 8E20A138C9D for ; Tue, 28 Apr 2015 19:34:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2476DE090B; Tue, 28 Apr 2015 19:34:03 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 71A5DE08BB for ; Tue, 28 Apr 2015 19:34:01 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YmZbl-0008AF-CG for gentoo-dev@lists.gentoo.org; Mon, 27 Apr 2015 05:21:21 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Apr 2015 05:21:21 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Apr 2015 05:21:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: RFC: c++14 global USE flag Date: Mon, 27 Apr 2015 03:21:13 +0000 (UTC) Message-ID: References: <20150424194217.0176adc0@googlemail.com> <553A91F6.7080505@gentoo.org> <553BA02E.7000805@gentoo.org> <20150425152317.20001.qmail@stuge.se> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT e424b98) X-Archives-Salt: d12ea313-b44d-4fab-b5e0-a58af331a427 X-Archives-Hash: ef34e87ccc1c6f8ab8e2cdec24ba3710 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