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

On Mon, 22 Sep 2003, David Schwartz wrote:
> > There will be a libpthread and -pthread will be NOOP'd.  It
> > should be a very familiar environment.
> 
> 	You know another environment that has '-pthread' (that is, it does not
> produce an error) but fails to compile and link pthreads code when that flag
> is supplied?

No.  There are other environments that don't have -pthread
though.

> > 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.
> 
> 	Yes, but it returns an error when '-pthread' is supplied.
> 
> > There should be very little problem for 3rd party applications.
> > -pthread won't cause an error.
> 
> 	That's the problem. This will dupe configuration scripts into believing
> that the option is supported.

No, some scripts use both -pthread and -lpthread together
already (on Linux!).  I just checked the configure script
in kdebase-3.1.3.  The threads library check seems to be
independent of the compiler check.  To test this, I made
a link from /usr/lib/libpthread.so to /usr/lib/libkse.so
and manually ran the configure script.  It worked just
fine.  It picked up -lpthread and didn't use -pthread (on
this system, -pthread still worked).

> 
> > 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.
> 
> 	Yes, by either removing the '-pthread' flag or making it work.

I'm all for removing it, but our FSF GCC maintainer thought
it better to make it a NOOP.  We're just going by his advice.

> 
> > 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.
> 
> 	The whole point of '-pthread' is to provide one standardized way to easily
> figure out what magic compiler/linker flags you need so you don't have to
> special case every platform. However, you are suggesting behavior for this
> flag that is unlike any other platform, turning the stardization attempt on
> its head.

Why do you want to shoehorn -pthread onto us when it is not
a good fit?

We don't have one standard library.  The example I like to
use is Solaris.  They have 2 thread libraries and have a
compiler switch for each one (-pthreads and -threads,
note -pthreads != -pthread).  Probably the reason they
have a compiler switch in the first place is because they
need to define __REENTRANT; FreeBSD doesn't need to
define anything.  If you are going to have more than
one compiler switch, then it defeats the purpose for it
because you might just as well use the correct link command.

Don't think about ports.  We have to make them PTHREAD_LIBS
compliant so the user can select a different library.  If
you want to argue that, then start another discussion
on ports about it.

This is about 3rd party applications built outside of
ports.  The only possible problem you are going to
have is on the link command, and it should be obvious
that you're missing a link to the threads library.
This is trivial to fix.  It's not like we're making
someone change their code to accomodate library or
kernel interface changes.

-- 
Dan Eischen