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

On Wed, 24 Sep 2003, Marcin Dalecki wrote:

> Daniel Eischen wrote:
> > On Tue, 23 Sep 2003, Marcin Dalecki wrote:
> > 
> > 
> >>Scott Long wrote:
> >>
> >>
> >>>I'm perfectly happy to support the libkse->libpthread switch, and I'm
> >>>perfectly happy to support making libpthread be the default threading
> >>>library.  But, I strongly believe that we need to also treat -pthread
> >>>sanely.
> >>
> >>You have to decide what the therading lib should be indeed.
> >>However recent expirence shows that a 1:n model seems to be the
> >>one the world over you is gearing around: Linux never did anything else.
> >>Windows anyway. Solaris switched from n:m to 1:n on the step between
> >>version 8 and 9.... Having two of them isn't the solution for me as a developer
> >>since I'm simply not interresed in debugging both cases.
> > 
> > 
> > This is a reason why -pthread shouldn't imply linking
> > to any one library.  If you only want to deal with
> > libthr or libthread (KSE in 1:1 mode), then you are
> > free to choose them and only them.
> 
> Last time I heard that "this is a link time option". So you are supposed
> to change the lib under the hood of the applications controll.

The applications is free to link to whatever it wants;
we're not changing that.  If it wants to link to 1:1
libthr or whatever, then it had better be sure to use
-lthr because -pthread won't do it regardless of whether
it is a NOOP or not.

> Making -ptherad empty is silly. If you are going to disable this
> perfectly sensible compiler switch then BY EVERY MEANS better make it BREAK
> CYRING ABOUT THIS FACT. But don't just silent it....

Making -pthread a NOOP _would_ (*) break the application
in the link stage; it would be obvious when the application
failed to link with lots of unresolved pthread symbols.

(*) Unless we want to support LD_PRELOAD being able
to change the threads library.

-- 
Dan Eischen