Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Feb 2014 22:07:55 -0800
From:      Garrett Cooper <yanegomi@gmail.com>
To:        Julio Merino <jmmv@outlook.com>
Cc:        freebsd-testing@FreeBSD.org, David Chisnall <theraven@FreeBSD.org>, Dimitry Andric <dim@FreeBSD.org>
Subject:   Re: Compile error with gcc
Message-ID:  <2281FB5D-2BF0-4763-AC24-67EC3864D39B@gmail.com>
In-Reply-To: <BLU0-SMTP35FABDADF1BB4D66F59E02C09E0@phx.gbl>
References:  <695E42A3-2009-4DD7-B10E-BF8465C89D39@gmail.com> <A8EF2DCC-5F11-4405-88D1-05A193AB7BAF@gmail.com> <D10C2EBB-36EC-4292-A944-4356EA5657F2@FreeBSD.org> <BLU0-SMTP284F6428835416F4D9E3727C09E0@phx.gbl> <849648F5-7834-45DD-8BDF-6385BF4F82DB@FreeBSD.org> <BLU0-SMTP35FABDADF1BB4D66F59E02C09E0@phx.gbl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 16, 2014, at 5:13 AM, Julio Merino <jmmv@outlook.com> wrote:

> On Feb 16, 2014, at 8:05, Dimitry Andric <dim@FreeBSD.org> wrote:
>=20
>> On 16 Feb 2014, at 13:45, Julio Merino <jmmv@outlook.com> wrote:
>>> On Feb 16, 2014, at 7:11, Dimitry Andric <dim@FreeBSD.org> 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. :-)
>=20
> 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?)
>=20
> If the above is true, then I'd just kill the whole =
HAVE_VSNPRINTF_IN_STD stupidity from both bconfig.h and application.cpp!

Thanks Dimitry for the input.

Should this check be done with=85

#if defined(__cplusplus) && __cplusplus >=3D <some-date>

etc, and if so, what c++ standard was vsnprintf incorporated into? It =
looks like <some-date> 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. Similarly, libc++ might need =
to be fixed to scope out -std properly, unless it=92s purely a c++11 and =
newer library.

Thanks!
-Garrett



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2281FB5D-2BF0-4763-AC24-67EC3864D39B>