weak implementation of threads has problems - kse fix attached

[Daniel Eischen]

On Tue, 8 Jun 2004, Sean McNeil wrote:
> As far as I can tell, there is no good reason.  So far, there has been a
> lot of talk about how to deal with threading because of this very
> issue.  Here is how threads were designed to work on all other
> platforms:
> 
> If a shared library wants to be thread-safe, they include CFLAGS
> definitions for any include file magic that may have to be done.  They
> do not link the shared library to the libpthread library.

This is wrong.  Most of the shared libraries in ports only
want to be thread-safe, yet they still link to libpthread.

> If a shared library is using threads (create, join, etc.) then they
> still do the CFLAGS defs but they also link to the pthread library.

There are not many (if any) of these libraries, but if there
are, then applications using those libraries should link to the
threads library of their choice.

> An application would link to the libraries they desire to use.  They
> don't care if some library they use pulls in pthread or not.  They only

They should care, especially since you can choose different
thread libraries.

> care when the application itself uses threads.  If it is a direct
> library dependency, the linker would make the application depend on
> pthread.  For instance, libORBit02.so.0 might be used by a gnome
> application, but it doesn't need to know or care that ORBit uses
> threads.
> 
> libc functions should be global symbols in libpthread that override the
> functionality usually provided by libc.
> 
> I fail to see why this is opposed by the FreeBSD community, the reasons
> behind the opposition, or why this entire thread has started trying to
> work around the mistake of making them weak symbols instead of just
> fixing the underlying problem by making them strong references.

Because there is no problem if you link correctly.  And I
would like to be able to override libc functions with my
own.  I wish malloc was weak.  I wish all our exported
symbols were weak.

See my earlier email for the advantage of not having shared
libraries linked to thread libraries (easier usage of
libmap.conf).

-- 
Dan Eischen