atom feed17 messages in org.freebsd.freebsd-currentRe: World breakage in libc_r?
FromSent OnAttachments
John PolstraOct 13, 1999 2:36 pm 
Doug RabsonOct 14, 1999 1:08 am 
Marcel MoolenaarOct 14, 1999 3:16 am 
Wilko BulteOct 14, 1999 9:45 am 
Kenneth Wayne CulverOct 14, 1999 12:09 pm 
Daniel EischenOct 14, 1999 12:20 pm 
John PolstraOct 14, 1999 2:06 pm 
John BirrellOct 14, 1999 2:19 pm 
Daniel EischenOct 14, 1999 2:34 pm 
John PolstraOct 14, 1999 2:44 pm 
John BirrellOct 14, 1999 2:53 pm 
Daniel EischenOct 14, 1999 3:25 pm 
David O'BrienOct 15, 1999 8:38 am 
Wilko BulteOct 15, 1999 11:09 am 
John BirrellOct 15, 1999 3:07 pm 
pa...@phoenix.volant.orgOct 15, 1999 3:23 pm 
John PolstraOct 17, 1999 10:16 am 
Subject:Re: World breakage in libc_r?
From:John Birrell (jb@cimlogic.com.au)
Date:Oct 14, 1999 2:53:25 pm
List:org.freebsd.freebsd-current

On Thu, Oct 14, 1999 at 05:35:05PM -0400, Daniel Eischen wrote:

One of the things on my wish list is a libpthread that can be linked with libc. So the way to accomplish this is to have null hooks with weak symbols in libc, and provide the same (non-null) functions in libpthread but with strong symbols?

Weak symbols don't work too well _between_ libraries. If libc is linked before libpthread, any unresolved references when libc is searched will use the weak symbols from there, regardless of the fact that a strong symbol exists in libpthread. If libc is linked after libpthread, then you can have libc internal references to things that should been resolved to things in libpthread, but end up using the weak symbols in libc because that is all there is left. 8-(

Not a simple problem to solve. The current tools don't help at all. A second library pass to resolve weak symbols would have been better. It's too late for that now, though, since you can change the semantics on the shared loader.

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message