Date: Thu, 31 Oct 2002 10:10:38 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: ak03@gte.com Cc: tlambert2@mindspring.com, dfr@nlsystems.com, current@FreeBSD.ORG Subject: Re: [PATCH: libc]Re: gnome on current Message-ID: <Pine.GSO.4.10.10210310956200.3821-100000@pcnet1.pcnet.com> In-Reply-To: <20021031094459.559e0292.kabaev@bellatlantic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Oct 2002, Alexander Kabaev wrote: > On Thu, 31 Oct 2002 09:08:12 -0500 (EST) > Daniel Eischen <eischen@pcnet1.pcnet.com> 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10210310956200.3821-100000>