From owner-freebsd-testing@FreeBSD.ORG Mon Feb 17 18:04:48 2014 Return-Path: Delivered-To: freebsd-testing@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 C9298B91; Mon, 17 Feb 2014 18:04:48 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F5621FB1; Mon, 17 Feb 2014 18:04:48 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::1d12:3dd7:fd12:f1d4] (unknown [IPv6:2001:7b8:3a7:0:1d12:3dd7:fd12:f1d4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5E8B05C45; Mon, 17 Feb 2014 19:04:45 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_E7E9F002-0DC8-4E3E-8CE6-67C871F511D2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Compile error with gcc From: Dimitry Andric In-Reply-To: Date: Mon, 17 Feb 2014 19:04:31 +0100 Message-Id: References: <695E42A3-2009-4DD7-B10E-BF8465C89D39@gmail.com> <849648F5-7834-45DD-8BDF-6385BF4F82DB@FreeBSD.org> <2281FB5D-2BF0-4763-AC24-67EC3864D39B@gmail.com> To: Julio Merino X-Mailer: Apple Mail (2.1827) 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: Mon, 17 Feb 2014 18:04:48 -0000 --Apple-Mail=_E7E9F002-0DC8-4E3E-8CE6-67C871F511D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 17 Feb 2014, at 14:55, Julio Merino wrote: ... > I'm not sure it's going to work. I think Dimitry mentioned that our = libstdc++ should already provide std::vsnprintf, but due to the flags = it's built with, it doesn't. I'm not sure if, due to this, the version = check above would do the right thing. Our libstdc++ config.h is configured that way, because if you run its = configure script, it notices that a few long double maths functions are = missing. Then it disables *all* C99 support in libstdc++, including all = the stuff we do have, like vsnprintf(). I'm not sure what would be broken if we overrode its automatic = detection, and forced libstdc++ to expose C99 functions. Maybe some = other programs would then complain about missing math functions... >> etc, and if so, what c++ standard was vsnprintf incorporated into? It = looks like should be 201103L (c++11) = (http://en.cppreference.com/w/cpp/io/c/vfprintf ). If so, then the = configure.ac tests should instead set the appropriate -std variable (or = setting), then test for c++=92s existence. >=20 > The point of tests in configure.ac scripts is to _not_ do the above = style of checks. If you are going to use those, then you don't need = configure because you can stick those into the code: configure should be = checking what the compiler actually does, not what it claims to support. = This way the checks are future-proof and are going to work even for = compilers you have not tried yet. >=20 > Note that the check in configure.ac is working just fine and that's = not the problem. The problem is in FreeBSD, where we have a single = bconfig.h for the two compilers and the two compilers behave differently = in at least one of the detected settings. It's not the compilers that behave differently, it is the C++ standard = library. If you compile with clang, but use -stdlib=3Dlibstdc++, you = will encounter the same issue, e.g. std::vsnprintf() will not be = available. > So... we could generate two bconfig.h files, one for each compiler, = and use them accordingly... or we could try to eliminate the divergence = altogether. To do the latter, I think it's enough to remove the = conditional and leave the code doing: >=20 > namespace std { > using ::vsnprintf; > } >=20 > in all cases. It works in clang but I don't know what the standard = has to say in this regard! You would simply be using the non-std version of vsnprintf(). I don't = think this should cause any trouble. Having said all this, I guess it would be simpler to just patch up our = libstdc++ to expose the functions we do have for C99, and not care about = what its configure script outputs. -Dimitry --Apple-Mail=_E7E9F002-0DC8-4E3E-8CE6-67C871F511D2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlMCTzsACgkQsF6jCi4glqMlogCgy7NanLOdqiErh9XUYNeXtFd4 x/cAoIr9KGAXJ9Ig000iVjKUeozbIqtF =bwVo -----END PGP SIGNATURE----- --Apple-Mail=_E7E9F002-0DC8-4E3E-8CE6-67C871F511D2--