Date: Thu, 05 Oct 2017 16:34:29 -0700 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Warner Losh <imp@bsdimp.com>, David Goldblatt <davidtgoldblatt@gmail.com>, Ian Lepore <ian@freebsd.org> Subject: Re: C++ in jemalloc Message-ID: <3760998.usdmS98HcN@ralph.baldwin.cx> In-Reply-To: <CANCZdfpFsMs48GoNcdcwqK2zM4-jNMNMAXbpkG408ysPAJfWnQ@mail.gmail.com> References: <CAHD6eXdazBO4=R7m5odWLt0YyAoTsuZTKvYbEh4_U5ZUXzxt9g@mail.gmail.com> <CAHD6eXepwKcUp6y6YVVLPeT5WKbp_jJJeO8troy%2BqJ4pTmYOWA@mail.gmail.com> <CANCZdfpFsMs48GoNcdcwqK2zM4-jNMNMAXbpkG408ysPAJfWnQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@bsdimp.com> wrote: > > > >> > >> > >> On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore <ian@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3760998.usdmS98HcN>