Comment on 'libc/signal/sigwait.c'.

[Peter S. Mazinger]

On Sat, 10 Dec 2005, Peter S. Mazinger wrote:

> On Sat, 10 Dec 2005, Steven J. Hill wrote:
> 
> > Peter,
> > 
> > Would you object loudly if I removed the '#define sigwaitinfo __sigwaitinfo'
> > from this file? We again have a NPTL version of '__sigwaitinfo' that you can
> > look at in 'libpthread/nptl/sysdeps/unix/sysv/linux/sigwaitinfo.c'. When we
> > go to use libpthreads, it would not use the correct function. Thanks.
> > 
> > -Steve
> 
> Well, yes ;-)
> 
> We need some solution to this generally.
> 
> What about:
> 1. define __libc_X in libc
> 2. define hidden_weak_alias(__libc_X,__X)
> 3. provide weak_alias(__X,X) for external apps within libc
> 4. use within libc __X exclusively, we need to use a hidden version to get 
> 	rid of the relocations (maybe one correctly, not with the define X 
> 	__X hack)
> 5. define __X in libpthreads (no weak), this will overwrite the hidden 
> weak __X in libc (I hope)
> 6. strong_alias(__X,X) in libpthreads
> 
> If an app external app does not use threads, it references X, (and will 
> use __X from libc and finally __libc_X), else if it uses pthreads, using X 
> gets the __X from libpthreads and that overwrites the weak __X in libc 
> (again I hope this). I am not sure (Jocke either), if the hidden weak in 
> libc can be overwritten by a strong one in libpthread

maybe it would work w/o __libc_X as well (some of glibc's files do it)

1. __X hidden in libc
2. weak_alias(__X,X)
3. __X hidden in libpthread
4. X strong_alias(__X,X)

external apps will catch the correct one (they only use X), so if they 
link against libpthread, they will use it's version, else the libc one
What happens though if libpthread has to overwrite the function in libc?
Are the 2 hidden versions capable of this?

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2