Re: CFT: patch for process shared pthread objects

On Tue, 30 Nov 2010, Anonymous wrote:

> David Xu <davidxu_at_freebsd.org> writes:
>
>> Garrett Cooper wrote:
>>
>>> Doesn't build :/...:
>>>
>>> ===> lib/libthr (obj,depend,all,install)
>>> make: don't know how to make thr_sleepq.c. Stop
>>> *** Error code 2
>>>
>> Sorry, I have updated it, please download it again, or just
>> download file:
>> http://people.freebsd.org/~davidxu/pshared/thr_sleepq.c
>> and put it in directory src/lib/libthr/thread/
>
> One more
>
>  cc -c [...] kern/kern_umtx.c
>  /usr/src/sys/kern/kern_umtx.c: In function '__umtx_op_lock_umutex_compat32':
>  /usr/src/sys/kern/kern_umtx.c:4107: error: too few arguments to function 'do_lock_umutex'
>  /usr/src/sys/kern/kern_umtx.c: In function '__umtx_op_wait_umutex_compat32':
>  /usr/src/sys/kern/kern_umtx.c:4128: error: too few arguments to function 'do_lock_umutex'
>  *** Error code 1
>
> As for runtime issues
>  - mplayer's vo_gl and vo_vdpau crash as do many GL games when using nvidia-driver
>  - csup hangs at the end of checkout

I'm not sure this is your problem, but as a note to others - if you
recompile any applications or libraries that use the new pthread
ABIs, you might have to rebuild all dependencies.  Just as when
we used to bump libc versions, you cannot use different pthread
ABIs in the same binary.  This is similar to the pre-symbol
versioning days when an older library libFOO was linked to
libc.so.5 and an application was rebuilt linking to both libFOO
and the newer libc.so.6.

This should only be a problem if any of the pthread types are
passed between applications and/or libraries; the older binary
will be expecting the older pthread type, but will be passed the
new pthread type.

So if you are going to use this patch, be careful about what
you rebuild.

-- 
DE