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

On Wed, 24 Sep 2003, Dan Nelson wrote:

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

Yes, it does matter.  There are no problems with exported pthread
symbols that I know of.  I believe it is private symbols (__foo)
that are causing problems and C++ style autoinit that is needed
to initialize the libraries.

We don't want applications to link to multiple thread
libraries anyways.  I don't know how to prevent it...

-- 
Dan Eischen