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

Doug Barton wrote:
> On Sun, 21 Sep 2003, John Birrell wrote:
> 
> 
>>On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote:
>>
>>>I am a little confused about one thing though. What is going to
>>>happen to third party apps that use -pthread that aren't compiled
>>>through the ports?
>>
>>They need to replace -pthread with their thread library of choice
>>(e.g. -lc_r or -lpthread).
> 
> 
> Errrr...  I'm not sure this is an optimal solution. There is an awful
> lot of software out there which expects -pthread to "just work."
> Wouldn't it make more sense to default it to one thing or the other,
> then make it configurable (isn't this what libmap.conf is supposed to
> help with)?
> 
> Doug
> 

I have to agree with this.  '-pthread' seems to have taken on the
meaning of 'turn on whatever magic makes the pthreads library work'.
The application writer is allowed to focus on the application, not
the FreeBSD-specific threading library options.  The user is allowed
to compile a third-party app without having to worry about the
FreeBSD-specific threading library options.  Everyone wins.

If we take the stand that any software that uses '-pthread' is broken
and should be fixed by the author, it will make FreeBSD wildly
unpopular.  If we take the stand that the only sactioned way to
compile a third-party app in FreeBSD is via the ports system, then
FreeBSD will become much less usable.

I've tried to stay silent on this issue in hopes that it would work
itself out, but I'm not quite sure that it is.  Making FreeBSD harder
to use and harder to program for in the name of pendanticy is not the
best direction.

Scott