From owner-freebsd-current Sun Mar 12 20:15:56 2000 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id A314037B70E for ; Sun, 12 Mar 2000 20:15:52 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <115222>; Mon, 13 Mar 2000 15:16:44 +1100 Content-return: prohibited From: Peter Jeremy Subject: Re: Weak symbols in libc_r broken? In-reply-to: <20000313145201.H34294@freebsd1.cimlogic.com.au>; from jb@cimlogic.com.au on Mon, Mar 13, 2000 at 02:45:16PM +1100 To: John Birrell Cc: current@FreeBSD.ORG Message-Id: <00Mar13.151644est.115222@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <20000313145201.H34294@freebsd1.cimlogic.com.au> Date: Mon, 13 Mar 2000 15:16:39 +1100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2000-Mar-13 14:45:16 +1100, John Birrell wrote: >the linker gives me the weak symbol version which refers to >_thread_sys_nanosleep (i.e. the syscall), instead of the nanosleep >function in libc_r. 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). >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. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message