From owner-freebsd-current@FreeBSD.ORG Sun Sep 21 01:38:30 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1636716A4B3; Sun, 21 Sep 2003 01:38:30 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5027643FBF; Sun, 21 Sep 2003 01:38:29 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id h8L8cSgG000024; Sun, 21 Sep 2003 04:38:28 -0400 (EDT) Date: Sun, 21 Sep 2003 04:38:28 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Doug Barton In-Reply-To: <20030921011930.K9576@znfgre.qbhto.arg> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: Fixing -pthreads (Re: ports and -current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2003 08:38:30 -0000 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