Date: Sun, 12 Nov 2006 02:54:38 +0900 From: Norikatsu Shigemura <nork@FreeBSD.org> To: des@des.no (Dag-Erling =?UTF-8?B?U23DuHJncmF2?=) Cc: freebsd-current@FreeBSD.org, nork@FreeBSD.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: libpthread vs libthr. Message-ID: <20061112025438.81de973a.nork@FreeBSD.org> In-Reply-To: <86lkmivws6.fsf@dwp.des.no> References: <20061110151247.GA64530@zone3000.net> <20061111022044.8191e1c8.nork@FreeBSD.org> <20061111065629.GA82094@xor.obsecurity.org> <20061111235332.89f24170.nork@FreeBSD.org> <86lkmivws6.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 11 Nov 2006 16:16:25 +0100 des@des.no (Dag-Erling Smørgrav) wrote: > Norikatsu Shigemura <nork@FreeBSD.org> writes: > > In this case, gdm tried to resolve a symbol, > > sched_yield@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@LIBTHREAD_1_0, Yes, libc have > > a sched_yield, but sched_yield@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061112025438.81de973a.nork>