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

From: Daniel Eischen <>
Date: Tue, 23 Sep 2003 09:53:22 -0400 (EDT)
On Mon, 22 Sep 2003, Scott Long wrote:

> Daniel Eischen wrote:
> > 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.
> > 
> This is exactly the case the is going to cause the problems, though.
> For you, compiling a 3rd party app and dealing with failures in the
> linker is easy to deal with.  For someone else, it might not be.  If
> they go to compile an app and it compiles and runs fine on linux but
> fails on FreeBSD with linker errors, it will likely leave a negative
> impression in their mind.
> I'm comparing my arguments to linux because a lot more apps are written
> with linux in mind than with solaris in mind these days.  People who are
> writing for linux or switching from linux might not know that
> '-lpthread' is a requirement, but they are more likely to know that
> '-pthread' will take care of all of that magic for them.  This argument
> really comes down to ease of use and user experience.  Steering away
> from de-facto standards steers us away from a positive user and
> developer experience.
> I'm perfectly happy to support the libkse->libpthread switch, and I'm
> perfectly happy to support making libpthread be the default threading
> library.  But, I strongly believe that we need to also treat -pthread
> sanely.

I stand by my opinion.  Also, you may end up breaking more
things if -pthread causes libpthread to be linked in.  Applications
that want to link with libthread (1:1), libc_r, or libthr
and use -pthread with -lpthread1:1, -lc_r, or -lthr will
break.  And it won't be obvious until weird things happen
when they run.

You guys are assuming this is going to cause large problems.
Just wait and see.

Dan Eischen
Received on Tue Sep 23 2003 - 04:53:25 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:23 UTC