Re: libpthread vs libthr.

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@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.

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@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.

--
DE_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: libpthread vs libthr.
    ... I read a discussion about libpthread vs libthr, ... and I resurrected to libpthread environment. ... My case is gdm. ... In this case, gdm tried to resolve a symbol, ...
    (freebsd-current)
  • Re: puzzled: fork +libthr
    ... From what I seem chromium does a bunch of forks before it gets to ... see that libthr and kernel have different opinions about what ... of its parent thread (the one that called fork). ... to both libc and libthr. ...
    (freebsd-hackers)
  • Re: puzzled: fork +libthr
    ... From what I seem chromium does a bunch of forks before it gets to the place of ... pthread_cond_wait call I see that libthr and kernel have different opinions ... But it seems that there are no pthread calls up the fork ... The second problem seems to be caused by chrome binary being linked to libc and ...
    (freebsd-hackers)
  • Re: puzzled: fork +libthr
    ... My debugging shows that those forks are "single-threaded" (i.e. code ... between userland and kernel in libthr, that mismatch leads to serious consequences. ... But it seems that there are no pthread calls up the fork ... The second problem seems to be caused by chrome binary being linked to libc and ...
    (freebsd-hackers)
  • Re: libpthread vs libthr.
    ... advantages of some special threading model, but still i would like to ... I read a discussion about libpthread vs libthr, ... and I resurrected to libpthread environment. ... My case is gdm. ...
    (freebsd-current)