Re: Fixing -pthreads (Re: ports and -current)

In the last episode (Sep 24), Daniel Eischen said:
> On Wed, 24 Sep 2003, Scott Long wrote:
> > Daniel Eischen wrote:
> > >   o Doesn't break applications that use both -pthread and
> > >     -l<threadlib>. We've been able to link both libc_r and libc
> > >     in -current for well over 2 years.  Indeed, if you build KDE
> > >     and X with libpthread installed, you will see binaries that
> > >     are linked to both libc_r and libpthread.
> > 
> > I can't see how this behaviour would not be considered a bug, if it
> > is indeed true.  Are you saying that there are packages out there
> > that will detect both -lpthread and -pthread and attempt to use
> > both on the compilers and linker lines?
> 
> Yes, it's not just that.  They can also find libc_r and include that
> (-lc_r) with -pthread.  I installed libkse as libpthread and made the
> appropriate links and built X and KDE and there were a lot of
> binaries that were linked to both libc_r and libpthread.

Does it really matter if you end up linked to multiple threads
libraries?  The first library providing a symbol wins, so the other
shlibs just won't get used at all.  Libraries linked from the
executable trump libraries linked from libraries, and LD_PRELOAD wins
above all.  If one threads library exports a symbol not in the others,
I'd call that an API bug in the first library.

This should be no different from explicitly linking in dmalloc to
override the malloc functions in libc, for example.

-- 
	Dan Nelson
	dnelson_at_allantgroup.com