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

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).
  o If we support LD_PRELOAD properly, will allow us to select the
    threads library without having to rebuild/relink the application.
  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.
  o Makes it easier to spot ports that are not PTHREAD_LIBS compliant.

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

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.

-- 
Dan Eischen