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: Andi Kleen <andi at firstfloor dot org>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: Torvald Riegel <triegel at redhat dot com>, 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>, andi <andi at firstfloor dot org>
- Date: Fri, 21 Jun 2013 19:47:10 +0200
- Subject: Re: Update on freeze status of glibc 2.18?
- References: <20130614224427 dot 4B2532C077 at topped-with-meat dot com> <51BF3CF8 dot 1010901 at redhat dot com> <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>
On Fri, Jun 21, 2013 at 10:17:10AM -0700, Richard Henderson wrote:
> On 06/20/2013 05:40 PM, Torvald Riegel wrote:
> > What I don't understand in your plan is how we deal with the case that
> > we have a PTHREAD_MUTEX_INITIALIZER in a program built against new glibc
> > headers, but executed with an older glibc version. In this case, the
> > new type values coming from the initializer wouldn't be understood by
> > the old pthread_mutex_lock(), for example.
>
> We should detect this case by versioning the pthread_mutex_lock function.
Well it would need lock/unlock/trylock/timedlock
Bumping version would be just trading an assert failure for a linker failure.
I'm not sure the linker failure will be any more comprehensible to
the user than the assert.
So for pthread_mutexattr_settype() the old glibc should just
reject the new value. So pthread_mutex_init() doesn't have this
issue.
And all the existing static initializers macros are also handled
by the old glibc.
The only case that would fail is the new static initializers with flags,
when the user sets elision flags.
If those are the show stopper I can remove them? It should be ok
to have to use function calls to set these attributes.
-Andi