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

On Sun, 21 Sep 2003, Scott Long wrote:

> Doug Barton wrote:
> > 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.

Most everyone that writes threaded applications and runs on
multiple platforms knows that most thread libraries are
called libpthread and are linked to with -lpthread.  Once
we rename libkse to libpthread, the problem largely goes
away.  The porter, or configure script, will find libpthread
and all should be fine.

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

There will be a libpthread and -pthread will be NOOP'd.  It
should be a very familiar environment.

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

As I've said in a previous email, Solaris doesn't have -pthread
and it hasn't seemed to cause any problems.  If you are going
to have -pthread (libpthread), -thread (libpthread1:1),
-thr (libthr), -uthread (libc_r), this is no different than
making them the appropriate link arguments.

There should be very little problem for 3rd party applications.
-pthread won't cause an error.  If there is any problem, it
will be on the link command and it should be very obvious
that a threading library wasn't pulled in.  Since a libpthread
will be present on the system, it's pretty much a no-brainer
how to fix the problem.

This is not like we're changing kernel or library interfaces.
I think folks are making a bigger deal out of it than it
really is.

-- 
Dan Eischen