Update on freeze status of glibc 2.18?

[Andi Kleen]

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