On Sat, 11 Nov 2006, Dag-Erling Smørgrav wrote: >> resolve a symbol, sched_yield(2). So X server didn't run. >> >> 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. Yah we do, see src/lib/libc/sys/Symbol.map. In the above case(s), libpthread and libthr use LIBTHREAD_1_0 as the version namespace. This was done back in 5.x. But now that libc has symbol versioning and the thread libraries want to override some symbols in libc, they (libc and the thread libraries) need to use the same version namespace. I added LIBTHREAD_1_0 as a compatibility hack to libpthread in -current, but it also has and defaults to FBSD_1_0 which is also used by libc. The way to fix this for the above problem is to enable symbol versioning (set SYMVER_ENABLED=yes in /etc/make.conf) and rebuild world. Then rebuild your ports. After that, all your ports will reference symbols in FBSD_1_0, and if libthr doesn't provide sched_yield_at_FBSD_1_0, it'll find it in libc. Before 7.0 goes out the door, symbol versioning will be enabled by default so you won't have this problem. -- DEReceived on Sat Nov 11 2006 - 16:33:41 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:02 UTC