On Sat, 11 Nov 2006 16:16:25 +0100 des_at_des.no (Dag-Erling Smørgrav) wrote: > Norikatsu Shigemura <nork_at_FreeBSD.org> writes: > > In this case, gdm tried to resolve a symbol, > > sched_yield_at_LIBTHREAD_1_0 instead of sched_yield. So by changing > > libthr by libmap, gdm couldn't resolve a symbol, sched_yield(2). > > libthr doesn't have a sched_yield_at_LIBTHREAD_1_0, Yes, libc have > > a sched_yield, but sched_yield_at_LIBTHREAD_1_0. > This is not a libthr issue, it's a symbol versioning issue. Arguably, > sched_yield should be removed from libpthread's symbol map, because > it's a wrapper for a syscall and we don't version syscalls. Sigh... Yes, it is not a libthr issue and a symbol versioning issue, but only a symbol versioning issue. (I think it is a issue that libpthread/libthr using SYMVER enabled by default. But TEST is significant:-) The point of these issues is a relation of FreeBSD system, kernel - libraries - userland(applications). We don't have a mutually commutative layer changing(almost works, but...). At least, we need re-compiling. At this time, I think that test is not enough.Received on Sat Nov 11 2006 - 16:54:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:02 UTC