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