From owner-freebsd-toolchain@FreeBSD.ORG Fri Jan 25 21:51:24 2013 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5D34193F; Fri, 25 Jan 2013 21:51:24 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 11870C36; Fri, 25 Jan 2013 21:51:23 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DF48E5C43; Fri, 25 Jan 2013 22:51:16 +0100 (CET) Message-ID: <5102FE56.40806@FreeBSD.org> Date: Fri, 25 Jan 2013 22:51:18 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Pedro Giffuni , Konstantin Belousov Subject: Re: Removing default build of gcc References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <20130125195941.GW2522@kib.kiev.ua> <5102ECBF.4060500@FreeBSD.org> <20130125204430.GX2522@kib.kiev.ua> <5102F107.8090501@FreeBSD.org> In-Reply-To: <5102F107.8090501@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 21:51:24 -0000 On 2013-01-25 21:54, Pedro Giffuni wrote: ... > I am aware a fix is being worked on. I think that as long as > the default compiler/C++ library works it is OK to make things > easier for other compilers. I am OK with having that change in > -current but for 9.x it is simply unacceptable. Actually, clang with libc++ works fine, and both clang and gcc with libstdc++ don't... If the problem is caused by the switchable libsupc++.so backend lib, I would have no trouble with reverting that. But do we know that for sure at this point? I have not spent enough time looking deeply into the issue. I did notice that libsupc++ .So objects get linked into libstdc++.so, even while they are also in libsupc++.so. Maybe that is causing trouble?