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

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