CXXSTD=c++11

[Dimitry Andric]

On 24 Mar 2016, at 23:51, Bryan Drewery <bdrewery at FreeBSD.org> wrote:
> 
> On 3/24/2016 3:45 PM, Bryan Drewery wrote:
>> On 3/24/2016 3:44 PM, Dimitry Andric wrote:
>>> On 24 Mar 2016, at 23:36, Bryan Drewery <bdrewery at FreeBSD.org> wrote:
>>>> 
>>>> Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
>>>> now?  We do this when using an external GCC since it doesn't default to
>>>> the c++11 standard quite yet.  As far as I understand, we require c++11
>>>> to build clang/libc++.
>>> 
>>> Yes, but it already passes -std=c++11 in the correct places, as far as I
>>> know.  E.g. during the clang and libc++ builds.
>>> 
>>> 
>>>> It seems to be the problem at
>>>> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-October/001757.html
>>>> which I've fixed in an upcoming commit to properly pass -std=c++11 to
>>>> the lib32 build in CXXFLAGS.
>>> 
>>> Hm, is this occuring during the build of libcxxrt, or of libc++?  If it
>>> is the former, then it seems that the system headers don't properly
>>> declare _Static_assert() in that case.  I have no clue as to why, though
>>> maybe it's picking something up from gcc's famously "fixed" standard
>>> headers?
>>> 
>> 
>> libcxxrt.
>> 
>> My fix also includes passing the proper -isystem =/usr/include/c++/v1 path.
>> 
>> I'll try without the -std change.
>> 
>> 
> 
> It fails without -std=c++11 (there's more discussion in that link and in
> PR 205453).

Yeah, I also commented on PR 205453 in the past, but I still don't
understand where the external gcc gets its _Static_assert macro from.
Or whether it gets it at all.  Maybe we should place a hack for this in
sys/cdefs.h?  We shouldn't litter contrib code with #ifdef GCC_VERSION
blocks.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20160324/9ca56801/attachment.sig>