This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: c++ source files in the build...
- From: Joseph Myers <joseph at codesourcery dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at sourceware dot org>, <fweimer at redhat dot com>, <schwab at linux-m68k dot org>, <libc-alpha at sourceware dot org>
- Date: Wed, 20 Jul 2016 17:00:19 +0000
- Subject: Re: c++ source files in the build...
- Authentication-results: sourceware.org; auth=none
- References: <xninwbjxj1.fsf@greed.delorie.com>
On Tue, 12 Jul 2016, DJ Delorie wrote:
> Is it worth fixing up all our internal headers and sources to be C++
> compatible? I.e. as a prelude to future C++ stuff? In this case, it's
> a utility to be installed alongside libc.so, not something inside
> libc.so itself, but still...
We have achieved the ability for bootstrap of a cross toolchain to be: (a)
build static-only, C-only GCC (does not require glibc headers to build);
(b) build glibc with that GCC, the resulting installation having identical
binaries (modulo debug info) to those you get from a longer alternating
sequence of GCC and glibc builds; (c) build full GCC with shared libraries
and C++ support. Ideally this would be even simpler (no rebuild of
compilers after glibc is installed, only of libgcc and building other GCC
libraries for the first time at that point).
Installing a C++ utility with glibc goes against that, as you can't build
it with the bootstrap compiler. I think any such utility should go in a
separate glibc-utils package (or multiple packages), released alongside
glibc but always built using installed headers and libraries rather than
using a glibc build tree and internal headers at all. I think
memusagestat should move into such a package, and potentially other
utilities (moving utilities used in the glibc testsuite would be
problematic, however).
--
Joseph S. Myers
joseph@codesourcery.com