Date: Mon, 13 Mar 2000 15:16:39 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: John Birrell <jb@cimlogic.com.au> Cc: current@FreeBSD.ORG Subject: Re: Weak symbols in libc_r broken? Message-ID: <00Mar13.151644est.115222@border.alcanet.com.au> In-Reply-To: <20000313145201.H34294@freebsd1.cimlogic.com.au>; from jb@cimlogic.com.au on Mon, Mar 13, 2000 at 02:45:16PM %2B1100 References: <20000313145201.H34294@freebsd1.cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2000-Mar-13 14:45:16 +1100, John Birrell <jb@cimlogic.com.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00Mar13.151644est.115222>