Date: Sat, 10 Apr 2004 23:12:40 +1000 From: Tim Robbins <tjr@freebsd.org> To: Matthias Schuendehuette <msch@snafu.de> Cc: freebsd-current@freebsd.org Subject: Re: libpthread? Message-ID: <20040410131240.GA60597@cat.robbins.dropbear.id.au> In-Reply-To: <200404101154.45195.msch@snafu.de> References: <200404101154.45195.msch@snafu.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 10, 2004 at 11:54:45AM +0200, Matthias Schuendehuette wrote: > I don't think that's intended. Am I overlooking something here? Is > 'libkse/libpthread' still not ready for KDE/GNOME and that's subject to > improve in the future? Is there a (usable) way to use 'libc_r' for KDE > *only* other than mapping each single KDE app seperately? You need to rebuild all ports that link to thread libraries, or that link to libraries that link to thread libraries. I tried doing this with portupgrade -a, but had no luck. I ended up deleting all installed packages and starting from scratch. After doing this, KDE - and everything else I've tried - works perfectly with libpthread. I now have nothing at all linking to libc_r, and I went as far as removing /usr/lib/libc_r* to reassure myself of this. If you're still having problems after rebuilding all your ports from scratch, post to -current with more details, or submit a bug report. > Perhaps someone is willing to explain and conclude the "do"s and > "don't"s around the different threading libraries (not only) to me. The golden rule is: don't mix threading libraries within a program. If a program is linked to libc_r, so must all the other thread-aware libraries it links to be. The same goes for libpthread. The silver rule is: if you're using the nvidia driver, set up your libmap.conf so that everything gets linked to libc_r. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040410131240.GA60597>