Date: Thu, 31 Oct 2002 15:09:11 +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: <20021031144953.E69202-100000@herring.nlsystems.com> In-Reply-To: <Pine.GSO.4.10.10210310926070.27891-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, Doug Rabson wrote: > > > On Thu, 31 Oct 2002, Alexander Kabaev wrote: > > > > > On Wed, 30 Oct 2002 22:25:12 -0500 (EST) > > > Daniel Eischen <eischen@pcnet1.pcnet.com> wrote: > > > > > > > > If last weak will win, the normal case when Xthrstub is loaded > > > > > _after_ libc_r will break. The only way to really fix this is to > > > > > export pthread_ symbols as strong in libc_r. Exporting them as weak > > > > > sounds like is a mistake which should be fixed. > > > > > > > > I disagree. See Solaris 6, 7, 8 & 9 for an example. > > > > > > > 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_??. > > > > > > Since in absolute majority of cases libc is the first library searched > > > for symbols, all pthread references will be bound to it and failure > > > described by Doug will not happen. > > > > > > Any library providing strong pthread_ definitions will be able to > > > override ones provided by the system. > > > > Something along these lines appears to work nicely and ought to work > > either with or without libXThrStub, which is now redundant since libc will > > be providing strong symbols that override all the weak symbols in > > libXThrStub. We should adjust the XFree86-4-libraries port to avoid > > building and using that library. > > Please no, you've got strong pthread_* symbols in libc. I'd rather > see them as strong in libpthread (but don't really want that either). > > You can also play the libgcc game inside of libc for those applications > or libraries that are too lazy to do it for themselves. Have the > libc pthread stubs key on a weak reference to pthread_create and > call the pthread_* if they are present. libXThrStub should be > able to do that though. It almost doesn't matter which of the solutions we use as long as we do something. What we currently have is clearly wrong but I'll list it along with the others. Solutions so far proposed are: 0. (Current behaviour). Define _pthread_* weakly in libc. A pthreads implementation defines strong _pthread_* symbols and weak pthread_* aliases for them. Anyone else which defines pthread_* symbols (either weak or strong) can take over and will normally end up breaking libc. 1. Define pthread_* strongly in libc. Make these strong symbols call weak _pthread_* counterparts also defined in libc. A pthreads implementation defines strong _pthread_* symbols allowing it to 'take over' from libc. 2. Define weak _pthread_* symbols in libc and probably weak pthread_* symbols either in libc or somewhere else (libXThrStub?). A pthreads implementation defines strong _pthread_* and strong pthread_*. This is the linux solution (without the _pthread_* indirection). 3. Like (0) but rewrite X11's thread code so that every call looks something like: if (pthreads) return pthread_foo(args); else return 0; This isn't likely to be easy to get back into the XFree86 codebase and makes us gratuitously different from the rest of the world, most of which neither need nor have libXThrStub. 4. Something else, e.g. more fine-grained control over symbol resolution beyond strong/weak. Probably not worth the effort. Right now, I can't tell what Solaris does. Alexander suggested that it was (1) but you disagree. It would be interesting to see the output of 'nm | grep pthread' for both libc.so and libpthread.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?20021031144953.E69202-100000>