From owner-cvs-all@FreeBSD.ORG Sun Aug 31 20:19:09 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF5FA16A4BF; Sun, 31 Aug 2003 20:19:09 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3DDC44005; Sun, 31 Aug 2003 20:19:08 -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.8/8.12.1) with ESMTP id h813J8tp020878; Sun, 31 Aug 2003 23:19:08 -0400 (EDT) Date: Sun, 31 Aug 2003 23:19:07 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Scott Long In-Reply-To: <3F52B5CE.8040905@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Joe Marcus Clarke cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/contrib/gcc/config freebsd-spec.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2003 03:19:09 -0000 On Sun, 31 Aug 2003, Scott Long wrote: > Daniel Eischen wrote: > > On Sun, 31 Aug 2003, Joe Marcus Clarke wrote: > > > > > >>On Sun, 2003-08-31 at 22:05, Scott Long wrote: > >> > >>>Daniel Eischen wrote: > >>> > >>>>deischen 2003/08/31 15:38:52 PDT > >>>> > >>>> FreeBSD src repository > >>>> > >>>> Modified files: > >>>> contrib/gcc/config freebsd-spec.h > >>>> Log: > >>>> Remove -pthread as a compiler option. It was deprecated 2.5 years > >>>> ago, but not removed. > >>>> > >>>> No reply from: threads, kan, obrien > >>>> > >>>> Revision Changes Path > >>>> 1.10 +2 -38 src/contrib/gcc/config/freebsd-spec.h > >>>> > >>> > >>>What is the consequence of this on ports/? I'm very much in > >>>favor of this change, but I'm wondering if more safety belts are > >>>needed. Also, are there any consequences on the doc/ and www/ > >>>areas? > > > > > > I don't know, but it hasn't been -pthread in current in over > > 2.5 years. Yes, -pthread was there as a bandaid, but it wasn't > > _the_ way to build threaded applications under -current. So, > > -pthread _was_ the safety belt. > > > > > >>I have a feeling we will see an increase of port build errors on > >>-CURRENT. This may not be a bad thing, though. It will show us which > >>ports are not using ${PTHREAD_LIBS} correctly. > > > > > > I agree. This is only the first step, though. Once ports > > get through this, there may be another hurdle once libkse > > becomes libpthread again. Autoconf may autodetect the presence > > of a libpthread and link to it, in conjunction with linking > > to ${PTHREAD_LIBS} being picked up somewhere else in the > > port. Just try building XFree86-4 or kde with libpthread > > (libkse installed as libpthread) and ${PTHREAD_LIBS} set > > to libc_r. It links to both libraries. > > > > This opens up very important questions. How do we smoothly make > the transition? What is the appropriate threading library for each > platform? Should 'libpthread' be a symlink, or should a library be > renamed? How do we answer these last two questions in a consistent > fashion? Where does libmap fit in? I'm (somewhat biased I guess) very much against making libpthread be anything other than what is now libkse. libkse was always suppose to be libpthread and offers real POSIX behavior (the 'p' in libpthread) unlike libthr. Solaris has both libpthread and libthread, neither of which are links. If you want one or the other, you link to the one you want. I don't see a reason why we should be any different. If you don't think about ports, then it should be more clear that that is how it should be. To confuse matters even more, once we change libkse back to libpthread, we will also be installing the 1:1 version of libkse as libthread (or some other name, but for now that's what we've chosen). We are ready to do this now, but will wait a bit to see how ports settle out with the removal of -pthread. BTW, I would also be against linking libpthread to the 1:1 version of libkse. -- Dan Eischen