From owner-freebsd-current@FreeBSD.ORG Tue Nov 12 20:19:23 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4677349; Tue, 12 Nov 2013 20:19:23 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 82FC0230D; Tue, 12 Nov 2013 20:19:23 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id rACKJMls004389; Tue, 12 Nov 2013 12:19:22 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id rACKJMFn004388; Tue, 12 Nov 2013 12:19:22 -0800 (PST) (envelope-from sgk) Date: Tue, 12 Nov 2013 12:19:22 -0800 From: Steve Kargl To: Dimitry Andric Subject: Re: Are clang++ and libc++ compatible? Message-ID: <20131112201922.GA4330@troutmask.apl.washington.edu> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131112175556.GA3319@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, David Chisnall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 20:19:23 -0000 On Tue, Nov 12, 2013 at 09:55:56AM -0800, Steve Kargl wrote: > On Tue, Nov 12, 2013 at 06:37:39PM +0100, Dimitry Andric wrote: > > On 12 Nov 2013, at 17:54, Steve Kargl wrote: > > > > > > struct Entry { > > > time_t date; > > > Severity severity; > > > std::deque messages; > > > std::string message; > > > bool is_child; > > > Entry() : is_child(false) { } > > > }; > > > > I think the problem is that the code tries to use std::deque as a > > member of struct Entry, before it is completely defined. This is not > > allowed by the standard, although some libraries (e.g. GNU libstdc++) > > apparently permit it for some container types. > > > > You could try to work around it with -fdelayed-template-parsing, but I > > am not sure if it will help. Alternatively, compile the code with > > libstdc++, or rewrite it to conform. :-) > > > > Thanks for the suggestions. -fdelayed-template-parsing did not > help. (Un)fortunately, I know very little about C++, so rewriting > the code is not option for me. I guess I'll add a USE_GCC to the > port's Makefile to if it will build. > 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) -- Steve