John Birrell wrote:
> Weak symbols don't work too well _between_ libraries. If libc is linked
> before libpthread, any unresolved references when libc is searched will
> use the weak symbols from there, regardless of the fact that a strong
> symbol exists in libpthread. If libc is linked after libpthread, then
> you can have libc internal references to things that should been resolved
> to things in libpthread, but end up using the weak symbols in libc
> because that is all there is left. 8-(
>
> Not a simple problem to solve. The current tools don't help at all. A
> second library pass to resolve weak symbols would have been better. It's
> too late for that now, though, since you can change the semantics on the
> shared loader.
It'd be interesting to know how Solaris does this. I see they don't
supply a static libpthread, just the dynamic. It seems they do use
a strong symbol in libpthread, and a weak one in libc:
vfr [80] $ nm /usr/lib/libc.so.1 | grep pthread_mutex_lock
[4394] | 596188| 44|FUNC |WEAK |0 |12 |_pthread_mutex_lock
[2980] | 596188| 44|FUNC |WEAK |0 |12 |pthread_mutex_lock
vfr [81] $ nm /usr/lib/libpthread.so.1 | grep pthread_mutex_lock
[333] | 20704| 8|FUNC |GLOB |0 |8 |_pthread_mutex_lock
[107] | 20704| 8|FUNC |WEAK |0 |8 |pthread_mutex_lock
Dan Eischen
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
