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

>
> On Wed, 24 Sep 2003, Scott Long wrote:
>
>> I'm a big advocate of using libmap to deal with this.
>
> Ditto.
>
> Based on the results seen thus far, my preference would really be for:
>
> (1) Keep -pthread, make it imply -lpthread, saving a lot of hassle.
>
> (2) Ship all packages and binaries using threading with -lpthread --
> i.e.,
>     a dynamic library dependency on libpthread.  This will mean that
> administrators don't have to list each possible threading library in
> /etc/libmap.conf in order to be sure they caught all of them.
>
> (3) Use libmap to perform the necessary substitution on a
> per-application
>     or per-system basis.  If libpthread isn't available on an
>     architecture, default ship libmap.conf to substitute libthr for
> libpthread on the platform for all applications.  Or libc_r, or
> whatever.
>
> This will result in all applications we ship having a consistent thread
> library name so that administrators can substitute more easily.
> libpthread would give you M:N threading by default, but it would be easy
> to perform local changes to improve performance for applications that
> specifically benefit from 1:1 threading, cothreads, etc.  Or if a
> serious compatibility bug is found between libpthread and an
> application, they can substitute easily as well.  I suppose this case
> might imply (4):
>
> (4) If an application is known to be compatible only with a specific
>     threading model, do hard-code that in the application build somehow.

This sounds to me like the best solution I've seen so far. We have libmap,
so why not use it? Only expert users will probably want to play with
different thread libraries, and they can find out about libmap.conf
themselves.

Arjan