libpthread vs libthr.
Norikatsu Shigemura
nork at FreeBSD.org
Sat Nov 11 17:54:52 UTC 2006
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.
More information about the freebsd-current
mailing list