From owner-freebsd-testing@FreeBSD.ORG Sun Feb 16 13:14:30 2014 Return-Path: Delivered-To: freebsd-testing@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 B3B3346E; Sun, 16 Feb 2014 13:14:30 +0000 (UTC) Received: from blu0-omc1-s25.blu0.hotmail.com (blu0-omc1-s25.blu0.hotmail.com [65.55.116.36]) by mx1.freebsd.org (Postfix) with ESMTP id 78E3C1C15; Sun, 16 Feb 2014 13:14:30 +0000 (UTC) Received: from BLU0-SMTP35 ([65.55.116.8]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Feb 2014 05:13:24 -0800 X-TMN: [Fqmecmpe2RlsJQ85xdVH0WrYfims44AM] X-Originating-Email: [jmmv@outlook.com] Message-ID: Received: from jmmv-macbookpro2.meroh.net ([108.176.158.82]) by BLU0-SMTP35.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Feb 2014 05:13:23 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Compile error with gcc From: Julio Merino In-Reply-To: <849648F5-7834-45DD-8BDF-6385BF4F82DB@FreeBSD.org> Date: Sun, 16 Feb 2014 08:13:24 -0500 Content-Transfer-Encoding: quoted-printable References: <695E42A3-2009-4DD7-B10E-BF8465C89D39@gmail.com> <849648F5-7834-45DD-8BDF-6385BF4F82DB@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1827) X-OriginalArrivalTime: 16 Feb 2014 13:13:23.0172 (UTC) FILETIME=[DEA6DA40:01CF2B18] Cc: Garrett Cooper , freebsd-testing@FreeBSD.org, David Chisnall X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 13:14:30 -0000 On Feb 16, 2014, at 8:05, Dimitry Andric wrote: > On 16 Feb 2014, at 13:45, Julio Merino wrote: >> On Feb 16, 2014, at 7:11, Dimitry Andric wrote: >>>=20 >>> I don't think this will always work correctly. If MK_LIBCPLUSPLUS = is >>> defined in bsd.own.mk, it only means libc++ is being *built*, not = that >>> it is being used. >>>=20 >>> It is probably easier and more fool-proof to check if = _LIBCPP_VERSION is >>> defined (which is the case when you use libc++) in bconfig.h, like = so: >>>=20 >>> Index: contrib/atf/bconfig.h >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- contrib/atf/bconfig.h (revision 261974) >>> +++ contrib/atf/bconfig.h (working copy) >>> @@ -56,7 +56,9 @@ >>> #define HAVE_UNSETENV 1 >>>=20 >>> /* Define to 1 if vsnprintf is in std */ >>> +#ifdef _LIBCPP_VERSION >>> #define HAVE_VSNPRINTF_IN_STD 1 >>> +#endif >>=20 >> Let's not do that unless we can change configure.ac to generate these = same contents. >>=20 >> Maybe we can just revert this to _not_ define HAVE_VSNPRINTF_IN_STD = as it used to be the case before the new import? Things were working = just fine with both libstdc++ and libc++ even if that setting was not = accurate for the latter... >=20 > Well, contrib/atf/atf-c++/detail/application.cpp has: >=20 > #if !defined(HAVE_VSNPRINTF_IN_STD) > namespace std { > using ::vsnprintf; > } > #endif // !defined(HAVE_VSNPRINTF_IN_STD) >=20 > so it sort of hacks around it anyway. :-) Right, so what does C++ say about this? Is that snippet OK even when = std::vsnprintf is already defined, as is the case for libc++? (I.e. = won't that using directive ever conflict with the library?) If the above is true, then I'd just kill the whole HAVE_VSNPRINTF_IN_STD = stupidity from both bconfig.h and application.cpp!=