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

On Sun, 21 Sep 2003, Doug Barton wrote:

> On Sun, 21 Sep 2003, Daniel Eischen wrote:
> 
> > Well, actually it is directly related.  Part of the plan to
> > transition to libpthread is making ports PTHREAD_LIBS compliant.
> > As stated in that thread, if a libpthread exists on the system,
> > autoconf/configure will pick it up and the port will also end up
> > using -pthread and/or PTHREAD_LIBS.  If PTHREAD_LIBS is set
> > to libthr or libc_r (something other than libpthread), then
> > the port ends up linking to both libraries.  This doesn't work
> > but you don't know it until your run the application and very
> > weird things happen.  Causing a clean breakage is better because
> > you know at compile-time that something is wrong.  So ports need to
> > first be PTHREAD_LIBS compliant before we make the switch.  Soon
> > after ports are fixed, we can rename it.
> 
> Where the ports are concerned, I think this is a reasonable course of
> action, and I'd like to thank you for backing out the -pthread change on
> HEAD. I am a little confused about one thing though. What is going to
> happen to third party apps that use -pthread that aren't compiled
> through the ports?

They'll have to choose one of our threading libraries.
-pthread will be a NOOP for them, so their application
will fail to link.

If the third party application is a library, it won't be as
obvious because it won't cause a compile or link error.  This
holds true for ports also.  It might not be that much of a
problem though, because applications that link to the third
party library can always link to whatever threads library
they want.  Then the third party library would end up using
the threads library chosen by the application.  This might
be the way to go for OpenGL or other similar libraries.  It
allows you to have applications linked with different thread
libraries and not be broken by OpenGL (or whatever) being
explicitly linked to a different threads library than the
application.

-- 
Dan Eischen