From owner-freebsd-current@FreeBSD.ORG Wed Nov 13 16:32:58 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B811C13A for ; Wed, 13 Nov 2013 16:32:58 +0000 (UTC) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7559B2D9F for ; Wed, 13 Nov 2013 16:32:58 +0000 (UTC) Received: from [80.67.16.112] (helo=webmailfront02.ispgateway.de) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1VgdLz-0000N0-UL for freebsd-current@freebsd.org; Wed, 13 Nov 2013 17:31:43 +0100 Received: from his1.his.de (his1.his.de [192.124.237.237]) by webmail.df.eu (Horde Framework) with HTTP; Wed, 13 Nov 2013 17:31:43 +0100 Date: Wed, 13 Nov 2013 17:31:43 +0100 Message-ID: <20131113173143.Horde.a-9M7JQ_vHo3tpDIMsGK6g1@webmail.df.eu> From: Marcus von Appen To: freebsd-current@freebsd.org Subject: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?) References: <20131112163219.GA2834@troutmask.apl.washington.edu> <77CB2B92-216A-4C80-B033-7E582B5F0DFC@FreeBSD.org> <20131112165422.GA2939@troutmask.apl.washington.edu> <20131112175556.GA3319@troutmask.apl.washington.edu> <20131112201922.GA4330@troutmask.apl.washington.edu> In-Reply-To: <20131112201922.GA4330@troutmask.apl.washington.edu> User-Agent: Internet Messaging Program (IMP) H5 (6.0.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Df-Sender: ZnJlZWJzZEBzeXNmYXVsdC5vcmc= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: mva@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 16:32:58 -0000 Steve Kargl : [...] > Sigh. Adding USE_GCC isn't the solution. > > % pan > Segmentation fault (core dumped) > % ldd /usr/local/bin/pan | grep ++ > libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c52bf000) > libc++.so.1 => /usr/lib/libc++.so.1 (0x3c81ea000) > > This can't be good. And, unfortunately, testing math/octave shows > no better :( > > % octave > Segmentation fault (core dumped) > % ldd /usr/local/bin/octave-3.6.4 | grep ++ > libstdc++.so.6 => /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) > libc++.so.1 => /usr/lib/libc++.so.1 (0x3c9801000) > This brings up another point into which I am running with the previously discussed blender issue. Let's assume port A_defcompiler does not specify a compiler and c++ lib, it will default to libc++ and clang++ on 10.x or newer, correct? If now a port B_gnuish depends on port A_defcompiler, but at the same defines GCC + libstdc++, the resulting binary might link against libc++ and libstdc++ at the same time. This in turn makes the port unusable. The same applies to the other way around. Right now we do not have mechanism to detect and handle those flaws. Maintainers might be even less aware of those issues. Does anyone know a proper way to deal with this at the moment on 10.x+ or is this something that was missed until now? Cheers Marcus