From owner-freebsd-ports@FreeBSD.ORG Mon Sep 9 09:47:02 2013 Return-Path: Delivered-To: freebsd-ports@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 ESMTP id C9AC867B for ; Mon, 9 Sep 2013 09:47:02 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.grem.de (outcast.grem.de [213.239.217.27]) by mx1.freebsd.org (Postfix) with SMTP id EE2C6245B for ; Mon, 9 Sep 2013 09:47:01 +0000 (UTC) Received: (qmail 3096 invoked by uid 89); 9 Sep 2013 09:40:19 -0000 Received: from unknown (HELO bsd64.grem.de) (mg@grem.de@93.215.179.56) by mail.grem.de with ESMTPA; 9 Sep 2013 09:40:19 -0000 Date: Mon, 9 Sep 2013 11:40:18 +0200 From: Michael Gmelin To: Dimitry Andric Subject: Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous Message-ID: <20130909114018.50ddbb3d@bsd64.grem.de> In-Reply-To: <0F2C94E4-A544-482F-A479-B7E70D49E615@FreeBSD.org> References: <201309072249.r87MnsLP052803@freefall.freebsd.org> <20130908081445.242f77c7@thor.walstatt.dyndns.org> <0F2C94E4-A544-482F-A479-B7E70D49E615@FreeBSD.org> X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: kde@FreeBSD.org, freebsd-current@freebsd.org, "O. Hartmann" , rakuco@FreeBSD.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 09:47:02 -0000 On Sun, 8 Sep 2013 14:57:01 +0200 Dimitry Andric wrote: > On Sep 8, 2013, at 08:14, O. Hartmann > wrote: > > On Sat, 7 Sep 2013 22:49:54 GMT > > rakuco@FreeBSD.org wrote: > > > >> Synopsis: > >> devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: > >> call to 'swap' is ambiguous > >> > >> State-Changed-From-To: open->patched > >> State-Changed-By: rakuco > >> State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 > >> State-Changed-Why: > >> I don't think the previous version worked. > >> > >> From your description, it looks like you've switched to building > >> with libc++ whereas libstdc++ was being used before. > >> > >> The upcoming Qt 4.8.5 plus a few patches which only made it to > >> 4.8.6 (but we've backported) will finally make Qt build with > >> libc++. > >> > >> We've just sent an exp-run request for Qt 4.8.5, and will hopefully > >> fix all these errors once it is committed. > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 > > > > I build the world/kernel since early this year with > > > > CXXFLAGS+= -stdlib=libc++ > > CXXFLAGS+= -std=c++11 > > > > > > in /etc/src.conf. I do not use those flags > > in /etc/make.conf! /etc/src.conf is supposed to target ONLY > > the /usr/src world, not the ports - this is as I interpret the man > > page for /etc/src.conf and it would be logical. But this > > rule/thinking seems to be broken by some includes > > from /usr/ports/Mk ingredients. > > Since r255321, -stdlib=libc++ is effectively the default, at least > when you haven't set gcc as the default compiler. So it also applies > to ports, which unavoidably will lead to a bit of fallout. My > personal experience is that most C++-based ports compile fine with > libc++ instead of libstdc++, except for a few that rely on internal > libstdc++ details. > > However, -std=c++11 is *not* yet the default, and C++11 has different > rules here and there, so some ports might fail to compile due to this. > For some ports, too much hacking may be required to make them work > with C++11. So in case of trouble, try removing -std=, or setting it > to different values (c++0x, c++98, gnu++98, etc), to get the port to > compile. > > Note the base system should have no problems with -std=c++11, so > please continue to use the option in src.conf, and report any > problems if you encounter them, so we can fix them. :-) > I've been using clang and libc++ successfully on 9.1-RELEASE for quite some time now. Based on what I've learned, expect the following pitfalls that might hit you hard in production: - Bugs in in libc++: CURRENT is good about pulling in fixes, but there are still quite basic things getting fixed, e.g. cout/cerr not being thread safe (this was supposedly fixed in CURRENT and STABLE just a few weeks ago). Another example was handling std::vector incorrectly (ouch). Other problems only affect C++11/C++14 features and shouldn't be a big issue when porting. - Mixed C++ library linkage: For some ports autoconf/libtool might pull in libstdc++ by accident, you really don't want this to happen since std types don't match (e.g. std::exception and everything inheriting from it, which will break exception handling in client code). - Incompatibilities in corner cases of the language: A good example is the exception specification of destructors. Those are defaulting to noexcept(true) now, while in C++03 it's the opposite. Even though it's bad design in almost all cases, the language permits throwing from destructors in general. I got hit by that when porting devel/ice, which depends on databases/db5, which has no exception specification for destructors, but throws from them under certain circumstances (e.g. database close failed), in that specific case also from callbacks that were called from within db5. Overall the code was quite convoluted, but valid C++03. On top of that there are the usual incompatibilities between implementations (like iostreams in gcc 4.2's libstdc++ does some things differently then the imho more compliant libc++) and compile time problems (like the swap issue you experiences, those are easy to fix). So the bottom line is: When converting a port to use clang++ -std=c++11 -stdlib=libc++, the fact that it builds ok and runs a couple of unit tests without problems is not enough. Cheers, Michael -- Michael Gmelin