This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Update on freeze status of glibc 2.18?
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Richard Henderson <rth at twiddle dot net>, Roland McGrath <roland at hack dot frob dot com>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Ryan Arnold <rsa at us dot ibm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Fri, 21 Jun 2013 22:48:05 +0200
- Subject: Re: Update on freeze status of glibc 2.18?
- References: <1371494971 dot 16968 dot 21574 dot camel at triegel dot csb> <20130617193649 dot 7B5872C08D at topped-with-meat dot com> <1371503900 dot 16968 dot 21902 dot camel at triegel dot csb> <20130619224234 dot 5AC132C10E at topped-with-meat dot com> <1371733830 dot 964 dot 1089 dot camel at triegel dot csb> <20130620230930 dot 6F21E2C135 at topped-with-meat dot com> <1371775236 dot 964 dot 3432 dot camel at triegel dot csb> <51C48A96 dot 9070606 at twiddle dot net> <20130621174710 dot GQ6123 at two dot firstfloor dot org> <51C4A3D7 dot 2030308 at twiddle dot net> <20130621191720 dot GR6123 at two dot firstfloor dot org>
On Fri, 2013-06-21 at 21:17 +0200, Andi Kleen wrote:
> > Certainly it is. Consider the following example, built on F19 (glibc 2.17) and
> > run on F18 (glibc 2.16):
> >
> > #include <time.h>
> > void *x = clock_nanosleep;
> > int main() { return 0; }
> >
> > $ ./z1
> > ./z1: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by ./z1)
> >
> > Given that we've used sensible names for our versions, I think that error
> > message is crystal clear.
>
> Ok. So AFAIK the assert failure can only happen with the new generic
> initializer, as pthread_mutexattr_settype always rejects any types
> it doesn't know about.
>
> So there are three options I see:
> 1. stay with the assert failures
> 2. add the new symbol versions (so that the error above is displayed)
> 3. remove the generic initializer.
>
> I personally would prefer 1. or 3. over 2. 2. seems quite intrusive
> to me, as it will cause quite a bit more failures in practice.
> I think losing the generic initializer isn't a too big loss.
3. would be okay for me at the current stage and the need to get
something in soon. All the user-provided per-lock customization is
something we can add later on once we agree on the details.
Also, we don't yet have consensus on the semantics of any elision flags
the user could provide (i.e., just performance hints vs.
semantics-modifying flags).