Re: C++ in jemalloc

In particular, it is expected that FreeBSD 12 will not ship with GCC 4.2 and
that all supported architectures in FreeBSD 12 will be using a C++11-capable
toolchain (either external GCC or in-tree clang).  However, older releases
will still be restricted to C++03 (or whatever GCC 4.2 supports) including
future releases on FreeBSD 11.  Also, FreeBSD-HEAD's tree is not yet in a
position where all architectures are using a C++11-capable toolchain.

On Thursday, October 05, 2017 04:13:08 PM Warner Losh 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
> >>
> >
> >
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"


-- 
John Baldwin