From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12066 invoked by alias); 25 May 2005 08:36:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 12014 invoked by uid 22791); 25 May 2005 08:36:47 -0000 Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 25 May 2005 08:36:47 +0000 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 9EF1D1253F; Wed, 25 May 2005 10:36:45 +0200 (CEST) Message-ID: <42943932.6020800@suse.de> Date: Wed, 25 May 2005 13:30:00 -0000 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Zack Weinberg , Gabriel Dos Reis , gcc@gcc.gnu.org, jason@redhat.com, mark@codesourcery.com, dberlin@dberlin.org Subject: libstdc++ soname and versioning (was: Re: Compiling GCC...) References: <1116907280.9577.31.camel@localhost.localdomain> <20050524035919.GA23335@nevyn.them.org> <87fywdkvmp.fsf@codesourcery.com> <20050524134120.GA1680@nevyn.them.org> <1116976827.8637.25.camel@localhost.localdomain> <4293BC92.3090404@suse.de> <1116980082.8798.8.camel@localhost.localdomain> <20050525001108.GA21632@nevyn.them.org> <1116981148.8798.11.camel@localhost.localdomain> <20050525014728.GA23626@nevyn.them.org> In-Reply-To: <20050525014728.GA23626@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg01359.txt.bz2 Daniel Jacobowitz wrote: >>Why? To be honest, I keep harping on this mostly because I think it >>should happen. All the C++-in-GCC noise is a digression. >> >>You know how much work it is for the distributors every time we bump the >>libstdc++ soname. Why wouldn't we want to stop inflicting that pain on >>them? >> >> >I know exactly how much work it is for Debian. I wouldn't mind slowing >down. I wouldn't mind using symbol versioning to solve the problem, if >I honestly thought that were feasible (which I don't, for a C++ >implementation library). But the fact of the matter is, the distros >know how to deal with this once in a while. I think that it's more >important that we continue to improve the library, for now. > >In a couple years I'll probably think differently. > I agree on both accounts. In practice, we have got an handful of bugs unfixable within the current ABI (mostly already fixed in v7) and a major QoI issue (ref-counted string vs MT) which certainly we don't want in anything "definitive" (x). Paolo. (x) What "definitive" really means in such contexts is an interesting semantic issue: *for sure* will end with C++0x ;)