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

Daniel Eischen wrote:
> On Tue, 23 Sep 2003, David Schwartz wrote:
> 
> 
>>>On Mon, 22 Sep 2003, David Schwartz wrote:
>>
>>>No.  There are other environments that don't have -pthread
>>>though.
>>
>>	So now FreeBSD will support a flag that numerous other platforms support,
>>however it will support it differently from every other platform. On every
>>other platform I know of where '-pthread' does anything other than generate
>>an error, it causes the compiler to conform to the pthreads standard.
>>FreeBSD will be the only platform that knows what '-pthread' is but doesn't
>>do the right thing when it gets it.
>>
>>	Isn't it good to have one flag that, on every platform that supports it,
>>gives you whatever's needed to get the default pthreads implementation to
>>work? And isn't that what '-pthread' was supposed to be for?
>>
>>
>>>Why do you want to shoehorn -pthread onto us when it is not
>>>a good fit?
>>
>>	Then don't support it. Return an error and nothing will break.
> 
> 
> You have the support of the threads guys here, including jb.  But
> we've been pushed the other way.
> 
> 
>>However, I'd
>>also suggest making it easy for people to set '-pthread' to give whatever
>>pthreads library they think is the most sensible default for their
>>installation.
> 
> 
> You can't make it variable.
> 
> I'm running out of energy here.  None of the threads guys want -pthread
> and if forced on them would prefer it to be a NOOP.  I am trying very
> hard not to be biased towards one threads library over another, and
> having -pthread automatically link to libpthread gives preference to
> it over libthr (or libthread (KSE in 1:1 mode) or libc_r).
> 
> Pros:
>   o Allows us to define macros common to all the threads libraries.
>   o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that
>     are not dependent on a particular threads library, but will use
>     whatever threads library the application uses (i.e., you want mplayer
>     to use libpthread and ogle to use libthr).

I'm a big advocate of using libmap to deal with this.

>   o If we support LD_PRELOAD properly, will allow us to select the
>     threads library without having to rebuild/relink the application.

I'm a big advocate of using libmap to deal with this.

>   o Doesn't break applications that use both -pthread and -l<threadlib>.
>     We've been able to link both libc_r and libc in -current for well
>     over 2 years.  Indeed, if you build KDE and X with libpthread installed,
>     you will see binaries that are linked to both libc_r and libpthread.

I can't see how this behaviour would not be considered a bug, if it is
indeed true.  Are you saying that there are packages out there that will
detect both -lpthread and -pthread and attempt to use both on the
compilers and linker lines?

>   o Makes it easier to spot ports that are not PTHREAD_LIBS compliant.

PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't
mean anything outside of that.

I suspect that the majority of users won't give a hoot about the
mechanics of all of this as long as it Just Works.  The more 
sophisticated users that want to mix/match threading libraries can be
expected to exert a little more effort and learn the tools like libmap,
etc.

> 
> Cons:
>   o Third party applications that use -pthread exclusively (without
>     linking to a threads library) will have to add a link option.

This is where I have the biggest problem.  I firmly believe that it is
incorrect for you to downplay this scenario, and it appears that others
agree too.  This is the case that will give us the black eye with users
and developers that want things to Just Work.

> 
> I understand that folks want to wave their hands and say "just make
> -pthread work and do whatever it needs to".  I'm like that myself.
> I just don't think it's a good idea.
> 

I'm unclear why it is impossible to do this.  The whole point of 
-pthread is to make it Just Work.  We have complete control over how
we make that happen.  Why is it impossible to make -pthread honor
PTHREAD_LIBS?  Why is it impossible to fix ports that try to
mix pthread schemas?

Scott