CXXSTD=c++11
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++. 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. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: CXXSTD=c++11
> On Mar 24, 2016, at 4:36 PM, Bryan Drewery 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++. > > 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. Wouldn’t that break the spark and mips builds if we did it always? They are the last stragglers to not have a working, fully vetted clang in the tree. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CXXSTD=c++11
On 3/24/2016 3:39 PM, Warner Losh wrote: > >> On Mar 24, 2016, at 4:36 PM, Bryan Drewery 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++. >> >> 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. > > Wouldn’t that break the spark and mips builds if we did it always? They are > the > last stragglers to not have a working, fully vetted clang in the tree. > *sigh* -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: CXXSTD=c++11
On 24 Mar 2016, at 23:36, Bryan Drewery 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? -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CXXSTD=c++11
> On Mar 24, 2016, at 4:42 PM, Bryan Drewery wrote: > > On 3/24/2016 3:39 PM, Warner Losh wrote: >> >>> On Mar 24, 2016, at 4:36 PM, Bryan Drewery 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++. >>> >>> 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. >> >> Wouldn’t that break the spark and mips builds if we did it always? They are >> the >> last stragglers to not have a working, fully vetted clang in the tree. >> > > *sigh* It wouldn’t take too much to unbreak the build for those platforms, though. And there’s been talk of kicking out gcc entirely for 11, which would force these ports to external toolchain builds, which wouldn’t be broken. So with the deadline 1 month away, what’s being done to de-orbit gcc, if anything? Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CXXSTD=c++11
On 3/24/2016 3:44 PM, Dimitry Andric wrote: > On 24 Mar 2016, at 23:36, Bryan Drewery 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. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: CXXSTD=c++11
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 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).
> /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -m32 -DCOMPAT_32BIT
> -mcpu=powerpc --sysroot=/usr/obj/powerpc.powerpc64/root/git/freebsd/lib32
> -L/usr/obj/powerpc.powerpc64/root/git/freebsd/lib32/usr/lib32
> -B/usr/obj/powerpc.powerpc64/root/git/freebsd/lib32/usr/lib32 -isystem
> /usr/obj/powerpc.powerpc64/root/git/freebsd/lib32/usr/include -isystem
> /usr/obj/powerpc.powerpc64/root/git/freebsd/lib32/usr/include/c++/v1
> -L/usr/obj/powerpc.powerpc64/root/git/freebsd/world32//root/git/freebsd/lib/libc++
> -pg -O2 -pipe -I/root/git/freebsd/lib/libcxxrt/../../contrib/libcxxrt -MD
> -MF.depend.guard.po -MTguard.po -fstack-protector-strong
> -Wno-error=unused-function -Wno-error=enum-compare
> -Wno-error=logical-not-parentheses -Wno-error=bool-compare
> -Wno-error=uninitialized -Wno-error=array-bounds -Wno-error=clobbered
> -Wno-error=cast-align -Wno-error=extra -Wno-error=attributes
> -Wno-error=inline -Wno-error=unused-but-set-variable -Wno-error=unused-value
> -Wno-error=strict-aliasing -Wno-error=addre
ss -c /root/git/freebsd/lib/libcxxrt/../../contrib/libcxxrt/guard.cc -o
guard.po
> --- guard.o ---
> /root/git/freebsd/lib/libcxxrt/../../contrib/libcxxrt/guard.cc:104:15: error:
> expected constructor, destructor, or type conversion before '(' token
> _Static_assert(sizeof(guard_t) == sizeof(uint64_t), "");
>^
> --- libelftc_dem_gnu3.So ---
> --- guard.o ---
> *** [guard.o] Error code 1
>
> make[4]: stopped in /root/git/freebsd/lib/libcxxrt
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: CXXSTD=c++11
On 24 Mar 2016, at 23:51, Bryan Drewery 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 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 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CXXSTD=c++11
On 3/24/2016 3:54 PM, Dimitry Andric wrote: > On 24 Mar 2016, at 23:51, Bryan Drewery 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 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. > Well _Static_assert is C++11 and static_assert is C11. These files are being built by GCC as C++03, so neither is presumably available without raising the standard. Shouldn't this be using static_assert with a CXXFLAGS+=-std=c++11 or CSTD=c11 ? -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: CXXSTD=c++11
On 3/24/2016 4:13 PM, Bryan Drewery wrote: > Well _Static_assert is C++11 and static_assert is C11. Yes I have it backwards, same point though. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: CXXSTD=c++11
On 24 Mar 2016, at 23:54, Dimitry Andric wrote: > > On 24 Mar 2016, at 23:51, Bryan Drewery wrote: ... >> 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. Hm, hacking around in cdefs.h also doesn't really help, because gcc refuses to recognize either _Static_assert or static_assert when it's not in C++11 mode. Reading back https://reviews.freebsd.org/D1390, I see that I originally wanted to avoid building libcxxrt with -std=c++11. This was so you could even build it with gcc 4.2.1 from base. However, it really doesn't make much sense to do so, and upstream libcxxrt simply uses static_assert directly, and requires -std=c++11. I will update the libcxxrt build to do so, probably tomorrow. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: CXXSTD=c++11
On 3/24/2016 4:16 PM, Dimitry Andric wrote: > On 24 Mar 2016, at 23:54, Dimitry Andric wrote: >> >> On 24 Mar 2016, at 23:51, Bryan Drewery wrote: > ... >>> 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. > > Hm, hacking around in cdefs.h also doesn't really help, because gcc > refuses to recognize either _Static_assert or static_assert when it's > not in C++11 mode. Reading back https://reviews.freebsd.org/D1390, I > see that I originally wanted to avoid building libcxxrt with -std=c++11. > This was so you could even build it with gcc 4.2.1 from base. > > However, it really doesn't make much sense to do so, and upstream > libcxxrt simply uses static_assert directly, and requires -std=c++11. I > will update the libcxxrt build to do so, probably tomorrow. > Sounds good. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: CXXSTD=c++11
On 3/24/2016 3:39 PM, Warner Losh wrote: > >> On Mar 24, 2016, at 4:36 PM, Bryan Drewery 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++. >> >> 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. > > Wouldn’t that break the spark and mips builds if we did it always? They are > the > last stragglers to not have a working, fully vetted clang in the tree. > When building with external GCC we're forcing it to use libc++ which uses static_assert which doesn't work without -std=c++11. The external GCC support now always forces -std=gnu++11 but I was testing with removing it. libatf blows up: > In file included from > /usr/obj/powerpc.powerpc64/root/git/freebsd/tmp/usr/include/c++/v1/ostream:137:0, > from > /root/git/freebsd/contrib/atf/atf-c++/detail/application.hpp:29, > from > /root/git/freebsd/contrib/atf/atf-c++/detail/application.cpp:26: > /usr/obj/powerpc.powerpc64/root/git/freebsd/tmp/usr/include/c++/v1/memory: In > member function 'void std::__1::default_delete<_Tp>::operator()(_Tp*) const': > /usr/obj/powerpc.powerpc64/root/git/freebsd/tmp/usr/include/c++/v1/memory:2514:13: > error: typedef '__t2514' locally defined but not used > [-Werror=unused-local-typedefs] > static_assert(sizeof(_Tp) > 0, "default_delete can not delete > incomplete type"); I stopped testing at this point. We've fixed it by always passing -std=gnu++11 to the entire build but then that ends up hiding other issues like that Static_assert in libcxxrt being misused. Not passing -std=c++11 to the lib32 build just happens to work because we don't normally build c++ libraries in it that don't otherwise force -std=c++11 (such as libc++ does now). -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
