From owner-freebsd-current Sun Mar 12 20:20:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id B415D37B549 for ; Sun, 12 Mar 2000 20:20:46 -0800 (PST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id PAA64349; Mon, 13 Mar 2000 15:28:40 +1100 (EST) (envelope-from jb) Date: Mon, 13 Mar 2000 15:28:40 +1100 From: John Birrell To: Peter Jeremy Cc: John Birrell , current@FreeBSD.ORG Subject: Re: Weak symbols in libc_r broken? Message-ID: <20000313152840.I34294@freebsd1.cimlogic.com.au> References: <20000313145201.H34294@freebsd1.cimlogic.com.au> <00Mar13.151644est.115222@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <00Mar13.151644est.115222@border.alcanet.com.au>; from Peter Jeremy on Mon, Mar 13, 2000 at 03:16:39PM +1100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Mar 13, 2000 at 03:16:39PM +1100, Peter Jeremy wrote: > Out of interest, why does nanosleep appear in libc_r.a as a weak > symbol version of _thread_sys_nanosleep at all? I would have thought > this was unnecessary (and based on my experiments, undesirable). I don't think it is necessary. It got caught up in the cancellation changes that Jason made. > > >Is there someone with a recent -current system who has time to try > >this out? > > I have -current from 9th March and get the same results you do. > Looking at last night's buildworld results, there doesn't appear to > be any change in the symbols in libc_r.a and when I try manually > performing the link with the ld in /usr/obj/..., I still get the > same result. > > >... then libc_r is broken. > > This is a particularly bad time to discover what appears to be a > fairly serious bug in the threaded libraries and/or linker. > > I just tried fiddling with the order in which uthread_nanosleep.o and > nanosleep.o appear in libc_r.a. It seems that the linker always picks > the first definition of the symbol found after the first reference to > the symbol - whether it is weak or not. Since nanosleep.o appears > before uthread_nanosleep.o, the non thread-safe version will be > picked. > > I suspect the only solution is to dispose of the weak symbols - > re-ordering the object file isn't an option given the requirement > for the non-weak symbol to always appear between the reference and > the weak symbol. I agree. Thanks for helping out. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@ca.com john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message