We can avoid it in the short term without a ton of pain. In the long run it would be nice to have, but I wouldn't want to tie our release schedule to FreeBSD's too tightly (our CI is improving to the point where the tip of the dev branch gets tested about as well as releases would be, so we're trying to de-emphasize release vs. non-release versions). Do you have a sense of when the situation might change (if only so I know when to check back)? Thanks for the replies on this, they've been super helpful. - David On Thu, Oct 5, 2017 at 4:13 PM, Warner Losh <imp_at_bsdimp.com> wrote: > Today C++11 is a no-go generally due to the lagging architectures needing > gcc 4.2. > > However, that answer might change soon. Would it be easy for you to avoid > C++11, or would that cause you significant pain? And what's the timeline > you'd be releasing a new jemalloc requiring this stuff? The answers might > change the 'no-go' to 'ok'. > > Warner > > > On Thu, Oct 5, 2017 at 3:00 PM, David Goldblatt <davidtgoldblatt_at_gmail.com > > wrote: > >> So it sounds like C++03 (or rather, the version of C++ supported by g++ >> 4.2) will be fine. >> >> Is C++11 a no-go, without breaking libc on non-Clang architectures? (It >> isn't clear to me if having to use the ports gcc to build was unfortunate >> or unacceptable from FreeBSD's POV). C++11 would be sort of helpful in the >> core implementation (we currently have to maintain our own backport of C11 >> atomics, for instance), but would be really helpful in the test suite >> (because of how much syntactically simpler it is to, say, spin up a bunch >> of threads to hammer a local instance of a data structure). >> >> - David >> >> On Thu, Oct 5, 2017 at 2:33 PM, Warner Losh <imp_at_bsdimp.com> wrote: >> >>> >>> >>> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore <ian_at_freebsd.org> wrote: >>> >>>> On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote: >>>> > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt >>>> > wrote: >>>> > >>>> > > >>>> > > Hi all, >>>> > > >>>> > > The jemalloc developers have wanted to start using C++ for a while, >>>> to >>>> > > enable some targeted refactorings of code we have trouble >>>> maintaining due >>>> > > to brittleness or complexity (e.g. moving thousand line macro >>>> definitions >>>> > > to templates, changing the build->extract symbols->rebuild mangling >>>> scheme >>>> > > for internal symbols to one using C++ namespaces). We'd been >>>> holding off >>>> > > because we thought that FreeBSD base all had to compile on GCC 4.2, >>>> in >>>> > > order to support some esoteric architectures[1]. >>>> > > >>>> > > The other day though, I noticed that there is some C++ shipping with >>>> > > FreeBSD; /usr/bin/dtc and /sbin/devd (the former claiming in the >>>> HACKING >>>> > > document that C++11 is a minimum for FreeBSD 11). This, combined >>>> with the >>>> > > fact that ports now points to a modern gcc, makes me think we were >>>> > > incorrect, and can turn on C++ without breaking FreeBSD builds. >>>> > > >>>> > > Am I right? Will anything break if jemalloc needs a C++ compiler to >>>> build? >>>> > > We will of course not use exceptions, RTTI, global constructors, >>>> the C++ >>>> > > stdlib, or anything else that might affect C source or link >>>> compatibility. >>>> > > >>>> > > Thanks, >>>> > > David (on behalf of the jemalloc developers >>>> > > >>>> > > [1] That being said, we don't compile or test on those >>>> architectures, and >>>> > > so probably don't work there in the first place if I'm being >>>> honest. But >>>> > > we'd also like to avoid making that a permanent state of affairs >>>> that can't >>>> > > be changed. >>>> > > >>>> > For FreeBSD 10 and earlier, this would likely break all architectures >>>> that >>>> > aren't x86. Starting in FreeBSD 11, arm and powerpc are supported by >>>> clang, >>>> > but not super well. For FreeBSD 12, we're getting close for everything >>>> > except sparc64 (whose fate has not yet been finally decided). >>>> > >>>> > So for the popular architectures, this arrangement might work. For >>>> building >>>> > with external toolchains, it might also work. Some of the less popular >>>> > architectures may be a problem. >>>> > >>>> > Does that help? It isn't completely cut and dried, but it should be >>>> helpful >>>> > for you making a decision. >>>> > >>>> > Warner >>>> >>>> Wait a sec... we've been compiling C++ code with gcc 4.2 since like >>>> 2006. What am I missing here that keeps this answer from being a >>>> simple "go for it"? >>>> >>>> Just stay away from C++11 features and gcc 4.2 should work fine. (DTC >>>> may require C++11, but that was likely the author's choice given that >>>> there was no requirement for it to work on pre-clang versions of >>>> freebsd). >>>> >>> >>> It's the ubiquity of C++11 is why I didn't just say "Go for it". >>> >>> Warner >>> >> >> >Received on Thu Oct 05 2017 - 21:50:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:13 UTC