From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 13:13:13 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 7FFA316A4B3; Tue, 23 Sep 2003 13:13:13 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65E4E43FE0; Tue, 23 Sep 2003 13:13:12 -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 h8NKDBgG019190; Tue, 23 Sep 2003 16:13:11 -0400 (EDT) Date: Tue, 23 Sep 2003 16:13:11 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Schwartz In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Doug Barton cc: Freebsd Current Subject: RE: Fixing -pthreads (Re: ports and -current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2003 20:13:13 -0000 On Tue, 23 Sep 2003, David Schwartz wrote: > > > On Mon, 22 Sep 2003, David Schwartz wrote: > > > No. There are other environments that don't have -pthread > > though. > > So now FreeBSD will support a flag that numerous other platforms support, > however it will support it differently from every other platform. On every > other platform I know of where '-pthread' does anything other than generate > an error, it causes the compiler to conform to the pthreads standard. > FreeBSD will be the only platform that knows what '-pthread' is but doesn't > do the right thing when it gets it. > > Isn't it good to have one flag that, on every platform that supports it, > gives you whatever's needed to get the default pthreads implementation to > work? And isn't that what '-pthread' was supposed to be for? > > > Why do you want to shoehorn -pthread onto us when it is not > > a good fit? > > Then don't support it. Return an error and nothing will break. You have the support of the threads guys here, including jb. But we've been pushed the other way. > However, I'd > also suggest making it easy for people to set '-pthread' to give whatever > pthreads library they think is the most sensible default for their > installation. You can't make it variable. I'm running out of energy here. None of the threads guys want -pthread and if forced on them would prefer it to be a NOOP. I am trying very hard not to be biased towards one threads library over another, and having -pthread automatically link to libpthread gives preference to it over libthr (or libthread (KSE in 1:1 mode) or libc_r). Pros: o Allows us to define macros common to all the threads libraries. o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that are not dependent on a particular threads library, but will use whatever threads library the application uses (i.e., you want mplayer to use libpthread and ogle to use libthr). o If we support LD_PRELOAD properly, will allow us to select the threads library without having to rebuild/relink the application. o Doesn't break applications that use both -pthread and -l. We've been able to link both libc_r and libc in -current for well over 2 years. Indeed, if you build KDE and X with libpthread installed, you will see binaries that are linked to both libc_r and libpthread. o Makes it easier to spot ports that are not PTHREAD_LIBS compliant. Cons: o Third party applications that use -pthread exclusively (without linking to a threads library) will have to add a link option. I understand that folks want to wave their hands and say "just make -pthread work and do whatever it needs to". I'm like that myself. I just don't think it's a good idea. -- Dan Eischen