On Tue, 29 Oct 2002, John Polstra wrote: > In article <[EMAIL PROTECTED]>, > Doug Rabson <[EMAIL PROTECTED]> wrote: > > On Tue, 29 Oct 2002, John Polstra wrote: > > > I think it would work if the symbol were defined strongly in libc_r. > > > > I think so too. I was trying to work out why this wasn't how things were > > done already. FWIW, linux's libpthread appears to be defining the > > pthread_* symbols strongly. > > I think the weak symbols have something to do with support for thread > cancellation. I didn't pay much attention at the time, so I don't > know the details. Here's the relevant commit message, I think (this > one taken from lib/libc_r/uthread/uthread_pause.c):
I wasn't paying attention to this thread until I got a glance at this message... FYI, we do the same thing as Solaris: bash-2.05$ uname -rvs SunOS 5.8 Generic_108528-12 bash-2.05$ nm /usr/lib/libpthread.so.1 | grep pthread_mutex_ 0000000000003d28 T _pthread_mutex_attr_gettype 0000000000003d20 T _pthread_mutex_attr_settype 0000000000003c38 T _pthread_mutex_consistent_np 0000000000003c78 T _pthread_mutex_destroy 0000000000003ca0 T _pthread_mutex_getprioceiling 0000000000003c70 T _pthread_mutex_init 0000000000003c80 T _pthread_mutex_lock 0000000000003c98 T _pthread_mutex_setprioceiling 0000000000003c90 T _pthread_mutex_trylock 0000000000003c88 T _pthread_mutex_unlock 0000000000003d28 W pthread_mutex_attr_gettype 0000000000003d20 W pthread_mutex_attr_settype 0000000000003c38 W pthread_mutex_consistent_np 0000000000003c78 W pthread_mutex_destroy 0000000000003ca0 W pthread_mutex_getprioceiling 0000000000003c70 W pthread_mutex_init 0000000000003c80 W pthread_mutex_lock 0000000000003c98 W pthread_mutex_setprioceiling 0000000000003c90 W pthread_mutex_trylock 0000000000003c88 W pthread_mutex_unlock All the pthread_* symbols are weak with the underscore versions being the strong ones. The same thing with libthread (_thr_* are the strong symbols, thr_* are weak). Why does libgcc have no problem? Is it because it uses weak references to the thread routines and avoids calling them until they are non-null? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
