Date: Sat, 7 Oct 2017 11:32:12 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: John Baldwin <jhb@freebsd.org>, "freebsd-arch@freebsd.org" <arch@freebsd.org>, Baptiste Daroussin <bapt@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171007083212.GV95911@kib.kiev.ua> In-Reply-To: <30849.1507334678@critter.freebsd.dk> References: <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <29630.1507308468@critter.freebsd.dk> <2706092.qpavixPdKK@ralph.baldwin.cx> <30849.1507334678@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 07, 2017 at 12:04:38AM +0000, Poul-Henning Kamp wrote: > -------- > In message <2706092.qpavixPdKK@ralph.baldwin.cx>, John Baldwin writes: > > >Hmm, I don't quite agree. I think it's possible to use a restricted C++ > >(no rtti, no exceptions, no STL) such that you are only using language > >features like templates or 'auto' without requiring runtime support. > > That's what Bjarne used to call "C++ as a better C compiler". > > If the jemalloc crew can stay inside that dotted line _and_ the C++ > compilers still allow you to do so, then that could be an "not quite > pregnant yet" option. > > >[...] > > >Right now the C++ runtime is split into a > >couple of different pieces: libc++ (STL bits, roughly), libcxxrt (rtti > >/ exception support), libgcc_s (either llvm libunwind or gcc for _Unwind_* > >along with intrinsics from compiler-rt). > >[...] > >I think bundling any of those pieces into libc makes our system less > >flexible and different from all the other UNIXy systems currently in > >vogue. > > That goes to my point about ld: The standard doesn't say which > library file which bits of the C++ runtime have to go into, we > get to decide that if we want to, as long as we provide a ld(1) > which knows where to find things. This is not how linkers work. The language standard does not say that, but the platform standards do: system ABI very much put the symbol origin in a stone. Dynamic libraries expose symbols under versions, if we ever expose some symbol under the specific version, we promise to do so to the end of times (or we break the ABI promise of stability). C++ runtime external symbols are already exported from the specific set of libraries. There are some tricks like filter objects which could somewhat alleviate the move, but maintaining them for third-party libs is too much efforts to ask, for almost no visible effect until things break. And of course there are parts of the C++ ABI which are underspecified by the Itanium ABI, which means that the ABI is not yet stable. Also we get the tie for specific compiler implementation, which runtime is imported. Since other compiler ABI is partially incompatible, but only partially, the other compiler would be impossible to use: some symbols resolution would come from our libc, some from the compiler libraries.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171007083212.GV95911>