Date: Sun, 21 Sep 2003 04:38:28 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Doug Barton <DougB@freebsd.org> Cc: current@freebsd.org Subject: Re: Fixing -pthreads (Re: ports and -current) Message-ID: <Pine.GSO.4.10.10309210427130.28556-100000@pcnet5.pcnet.com> In-Reply-To: <20030921011930.K9576@znfgre.qbhto.arg>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309210427130.28556-100000>