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 - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/
[EMAIL PROTECTED] [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
