RFC: [Long] Change PTHREAD_LIBS to -pthread for -CURRENT

[Charles Swiger]

On Jun 8, 2004, at 12:17 PM, Michael Nottebrock wrote:
> On Tuesday 08 June 2004 10:41, John Birrell wrote:
>> The reason was that the gcc people want -pthread to be the standard
>> way of sucking in thread support via their compiler. They intend the
>> -pthread option to be used across all operating systems, notably
>> including Linux.
>
> I see. How do we address the issue of having multiple threads 
> libraries to
> choose from then? I take it using the libmap feature is not the answer.

First, I'm fully in favor of using "-pthread" to tell the compiler 
"compile and link the code using whatever additional flags and 
mechanisms are necessary to support POSIX threads", rather than having 
to specific some combination of "-D_THREAD_SAFE -DPIC -lpthread", etc, 
particularly as that combination changes from OS to OS, or even from 
release to release within a specific OS.

Second, LD_PRELOAD is intended to solve the issue of "how do I 
substitute a different version of a shared library (so long as it 
provides the symbols needed by the program so that the executable 
dynamicly links) than the one the program was actually linked against".

Solaris uses this mechanism to support different flavors of malloc 
besides the default SCD-compliant one, such as bsdmalloc and mapmalloc, 
and it also uses this mechanism to provide backwards compatibility with 
buggy programs as per "man ld.so.1":

NOTES
      The user compatibility library /usr/lib/0 at 0.so.1 provides  a
      mechanism  that establishes a value of 0 at location 0. Some
      applications exist that erroneously assume a null  character
      pointer  should  be  treated the same as a pointer to a null
      string. A segmentation violation will occur in these  appli-
      cations  when  a null character pointer is accessed. If this
      library is added to such an  application  at  runtime  using
      LD_PRELOAD,  it  provides an environment that is sympathetic
      to this errant behavior.  However,  the  user  compatibility
      library is intended neither to enable the generation of such
      applications, nor to  endorse  this  particular  programming
      practice.

For this to actually be useful (usable?) under FreeBSD, the implication 
is that the different thread libraries which exist under FreeBSD need 
to be interchangable via dynamic linking, rather than requiring 
compile-time changes to the code using threads.  I don't know whether 
libpthreads, libc_r, and libkse can be switched using dynamic linking, 
but if they can't, pick the best implementation and make it the default 
that "cc -pthreads" uses.

-- 
-Chuck