Fixing -pthreads (Re: ports and -current)

[Daniel Eischen]

On Wed, 24 Sep 2003, Scott Long wrote:

> Daniel Eischen wrote:
> > 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.

It isn't clear that libmap can deal with libraries that are
linked to one specific threads library, and how libmap'd
applications work.  If mplayer is libmap'd to libthr,
ogle is libmap'd to libpthread, and both are linked to
libGL which is linked to libc_r, what happens?

At the least, -pthread should be a NOOP when building
shared and dynamic.

> >   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.

libmap is in /etc and not writable by normal users.
LD_PRELOAD can be set in a script or command line.
Our FSF GCC maintainer has been advocating it and
it solves the problem without the need for libmap.

> 
> >   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?

Yes, it's not just that.  They can also find libc_r and include
that (-lc_r) with -pthread.  I installed libkse as libpthread and
made the appropriate links and built X and KDE and there were
a lot of binaries that were linked to both libc_r and libpthread.
Perhaps this is because some shared libraries were linked to
one or the other while the applications got linked to the other
one -- I don't know.  Making -pthread a NOOP when building
shared libraries may help the situation.

> >   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.

That just meant it makes it easier to maintain ports so that
they are PTHREAD_LIBS compliant (they would break when linked).
I know it has no bearing on 3rd party stuff.

> 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.

Well, we can agree to disagree :-)  I think folks are getting
upset that -pthread is an error and seeing all the problems
in ports and thinking the same thing is going to happen in
3rd party applications.  Things aren't nearly as broke when
it is a NOOP _and_ we have libpthread installed.  Any configure
script I've seen looks for -lpthread and will use it.

> > 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?

PTHREAD_LIBS is an bsd.port.mk thing.  -pthread is a compiler
switch (contrib/gcc/config/freebsd-spec.h).  I certainly don't
know how you would do this.

>  Why is it impossible to fix ports that try to
> mix pthread schemas?

It's not impossible, it's just not as easy to spot them because
they don't break when building.  You have to wade through complaints
saying "X doesn't work correctly, what happened?" and hopefully
get an 'ldd X' out of them so you can spot the problem.  Then
you have to figure out if it was the X port or something else
that it is linked to which has the problem.  We can do it, it's
just not as simple as a link error when the port fails to build.

I'm done.  I've presented my points and should have given up
before now.  You guys do what you want.  Take it to -arch
or TRB or whatever, I don't care.  Just tell me what to
do with -pthread and I'll do it.  At this point, the only
things I care about is that libkse gets renamed to libpthread
(perhaps after sparc64 and alpha support) and that -pthread
be a NOOP when building shared libs.

-- 
Dan Eischen