weak implementation of threads has problems - kse fix attached

[John Birrell]

On Tue, Jun 08, 2004 at 01:34:33AM -0400, Daniel Eischen wrote:
> On Tue, 8 Jun 2004, John Birrell wrote:
> 
> > [ cross-post lists cut back, ports added 8-) ]
> > 
> > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote:
> > > A good addition to bsd.port.mk, right next to the "possible network
> > > server" etc checks, might be to run ldd on all installed shared
> > > libraries and print a warning if any threads libraries show up.  There
> > > are a huge number of ports that install shlibs linked to libpthreads.
> > 
> > Good idea.
> 
> Just picking a message at random to reply to...
> 
> In case anyone wonders why we don't use strong references, I chose to
> mimic what Solaris does:
> 
>   bash-2.05$ nm /lib/libpthread.so.1 | grep pthread_mutex_lock
>   0000000000003c80 T _pthread_mutex_lock
>   0000000000003c80 W pthread_mutex_lock
> 
>   bash-2.05$ nm /lib/libc.so.1 | grep pthread_mutex_lock
>   0000000000096c38 W _pthread_mutex_lock
>   0000000000096c38 W pthread_mutex_lock
> 
> It is also easy to provide your own version of pthread_foo() without
> having any strong references override it.

Despite the heat-of-the-moment on amd64, FWIW, using linpthread on i386
on a clean machine with NOLIBC_R set in /etc/make.conf, nothing in libmap.conf
and just normal ports builds, gnome, mplayer, mozilla, openoffice etc work
fine for me on current (except for the ACPI kernel problems which should
either be fixed or backed out IMNSHO).

-- 
John Birrell