Date: Thu, 31 Oct 2002 15:23:35 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: ak03@gte.com, <tlambert2@mindspring.com>, <current@FreeBSD.ORG> Subject: Re: [PATCH: libc]Re: gnome on current Message-ID: <20021031151314.A69202-100000@herring.nlsystems.com> In-Reply-To: <Pine.GSO.4.10.10210310956200.3821-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Oct 2002, Daniel Eischen wrote: > 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 Now I'm really confused. I can't see how this can work properly. Imagine the following scenario: An application 'base' is linked against libc and is not threaded. This application loads a plugin 'Xplug.so' via dlopen(). Xplug doesn't use threads but it does link against libX11.so which calls pthread_mutex_* etc. to ensure thread-safety. Since libX11 doesn't want to force threading unless its needed, it just uses libc's weak versions. Finally, 'Threadplug.so' is loaded which does use threads. This object is linked with libpthread.so which is now in the list of libs, crucially *after* libc.so. After all this loading and runtime linking, the question is how does libX11 manage to call the right pthread routines? It isn't linked directly to libpthread.so and the first weak definition of pthread_foo is from libc.so. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 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?20021031151314.A69202-100000>