On Thu, 31 Oct 2002, Alexander Kabaev wrote: > On Thu, 31 Oct 2002 09:08:12 -0500 (EST) > Daniel Eischen <[EMAIL PROTECTED]> wrote: > > > > Cool. Then let's be consistent and follow Solaris all the way. Libc > > > on Solaris provides full set of pthread_? functions which in turn > > > call weakly defined _pthread_?? counterparts. libpthread in turn > > > provides strong definitions for _pthread_??. > > > > No, please see earlier messages in this thread. > > > > Dan, > > could you please be consistent? You cited Solaris as an example against > making all the symbols in libc_r strong. I gave you an answer that the > only way why this works on Solaris is because libc itself provides weak > pthread_ definitions. pthread_ functions in libc simply call their > _pthread counterparts, which are also weekly defined in libc. libpthread > defines _pthread_ symbols as strong and consequently its symbols > override one provided by libc.
No, you stated that Solaris libpthread defines pthread_ symbols strong. It doesn't. Perhaps you really meant _pthread_ symbols, which is what you say above. For the record, neither libc nor libthread or libpthread in Solaris provide strong pthread_* symbols. They (Solaris) do provide strong _pthread_* symbols in libpthread, as we do in libc_r. bash-2.05$ uname -rvs SunOS 5.8 Generic_108528-12 bash-2.05$ nm /usr/lib/libpthread.so.1 | grep pthread_mutex_lock 0000000000003c80 T _pthread_mutex_lock 0000000000003c80 W pthread_mutex_lock bash-2.05$ nm /usr/lib/libc.so.1 | grep pthread_mutex_lock 0000000000096c38 W _pthread_mutex_lock 0000000000096c38 W pthread_mutex_lock We also have an additional requirement in libc. Our uses of _pthread_* in libc must correspond to the [single underscore] _pthread_* in libc_r (and libpthread eventually). All references to [non underscore] pthread_* routines must correspond to the [two underscore] __pthread_* routines in libc_r. This is so our threads libraries can tell the difference between application and implementation locks. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
