This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Minimum GCC version for building glibc
- From: Richard Henderson <rth at twiddle dot net>
- To: Joseph Myers <joseph at codesourcery dot com>, Torvald Riegel <triegel at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Thu, 06 Nov 2014 09:41:20 +0100
- Subject: Re: Minimum GCC version for building glibc
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1410311352200 dot 4263 at digraph dot polyomino dot org dot uk> <20141104165815 dot GK5402 at vapier dot wh0rd dot info> <5459239B dot 4020901 at cs dot ucla dot edu> <20141104214726 dot EF16D2C244F at topped-with-meat dot com> <1415158871 dot 4531 dot 60 dot camel at triegel dot csb> <alpine dot DEB dot 2 dot 10 dot 1411051629250 dot 1007 at digraph dot polyomino dot org dot uk>
On 11/05/2014 05:34 PM, Joseph Myers wrote:
>> > really looked at what to do when GCC's libatomic would implement certain
>> > atomics (e.g., when the kernel is used) -- should we just use libatomic,
>> > or would we need to keep rolling our own.
> My inclination is to keep rolling our own. I suspect libatomic might be
> troublesome in bootstrap builds (where the desire is for glibc built with
> an initial static-only GCC, itself built without C library headers, to be
> identical to glibc built from a longer iteration of alternating GCC and
> glibc builds). And any libatomic operations based on locks (e.g. the
> operations for arbitrary-sized types) obviously aren't suitable for glibc
> use (depending as they do on pthread_mutex_lock).
Agreed, more or less.
I'd been thinking that while we wouldn't actually link against gcc's libatomic
we could, as needed, implement the same __atomic_* functions, so that the
normal builtins Just Work. We would of course not export these symbols, so
that normal user use of these would bind to libatomic.
r~