On 2000-Mar-13 14:45:16 +1100, John Birrell <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
