Re: C++ in jemalloc

I'm guessing a realistic timeline for us would be on the order of 3 to 6
months. We've been dithering on this issue for a while, and your request
seems as good a time as any to get people off the fence...

So, if you are targeting FreeBSD 12, then in that time frame, there'd be no
issues with C++11 in the form you characterized. FreeBSD 11.x couldn't
handle requiring a c++11 compiler to build though, and we're planning
another release of that soon.

Warner

On Thu, Oct 5, 2017 at 4:50 PM, David Goldblatt <davidtgoldblatt_at_gmail.com>
wrote:

> 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
>>>>
>>>
>>>
>>
>