Re: libpthread?

On Sat, 10 Apr 2004, Tim Robbins wrote:

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

You don't need to rebuild any ports if you globally
map libc_r to libpthread with /etc/libmap.conf.  Over
time, when all your ports are upgraded at your leisure,
references to libc_r will be removed.  Of course,
portupgrade -af would do the trick much quicker...

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

If you are coming from 5.2.1-RELEASE and before, and trying
to upgrade to -release, the default threading library changed
from libc_r to libpthread.  This would explain how you would
be mixing threading libraries and why you need to (at least
temporarily) use /etc/libmap.conf to choose one.

> The silver rule is: if you're using the nvidia driver, set up
> your libmap.conf so that everything gets linked to libc_r.
> 

-- 
Dan Eischen