From owner-cvs-all@FreeBSD.ORG Sun Aug 31 23:24:41 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 66C2F16A4C1 for ; Sun, 31 Aug 2003 23:24:41 -0700 (PDT) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 7BAE044003 for ; Sun, 31 Aug 2003 23:24:35 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: (qmail 44071 invoked by uid 1002); 1 Sep 2003 06:24:34 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 1 Sep 2003 06:24:34 -0000 Message-ID: <3F52E616.3050201@freebsd.org> Date: Mon, 01 Sep 2003 00:24:22 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Birrell References: <20030901045513.GA91654@dragon.nuxi.com> <20030901160120.A1311@freebsd1.cimlogic.com.au> In-Reply-To: <20030901160120.A1311@freebsd1.cimlogic.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: deischen@FreeBSD.org cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: David O'Brien 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 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 06:24:41 -0000 John Birrell wrote: > On Mon, Sep 01, 2003 at 01:22:47AM -0400, Daniel Eischen wrote: > >>>{Net,Open}BSD and Linux all accept the "-pthread" option. By removing >>>support for it we are the odd man out on accepted GCC options. You also >> >>{Net,Open}BSD have it because they had the same problem with >>libc_r (it couldn't be linked with libc). Since when did Linux >>get this hack and why? > > > When the -pthread argument was added to FreeBSD's gcc, it was because > the initial thread work wasn't allowed to 'touch' libc. That was > off-limits. Times have changed and it's time we moved on from that > position. Once libc was 'allowed' to have stubs in it for thread-specific > data, mutexes, condition variables, etc, there was no need to have > a separate library. > > I don't remember any of the operating systems mentioned having -pthread > back then. Perhaps my memory is vague. That fact that they have it now is > nothing more than a curiosity IMO. > Rehat GCC 2.96 and 3.2 both support the -pthread option, though its function is _quite_ vague: `-pthread' Adds support for multithreading with the "pthreads" library. This option sets flags for both the preprocessor and linker. I'm not in the mood to go digging though SRPM packages to look for the real meaning of this, so YMMV. That said, I'm really not against removing '-pthread'. It causes endless confusion for people like me who don't quite pay enough attention but still remember when it did magical things. I know that it has been 'deprecated' for a number of years, but maybe it's time to make gcc actually spit out warnings when it's used? Dunno. Whatever moves us forward with the least amount of pain. > >>Are we talking about buildworld or ports? I know we are >>breaking 3rd party makefiles, but we need to do that >>and knew over 2 years ago. > > > If we're talking about things in 5.X that affect third party developers, > let me say that a compiler option is the least of the problems they > will encounter. I'm going through that 'little' exercise now. And what > fun it is. Not. > > FWIW (probably not much), I support Dan's position on this. I'd like to > see kse become the default as a true libpthread as has been assumed in > all the work that those guys have done. > > I'll go one step further and say that I don't think libthr should be in > the tree. And libc_r should be shot just as soon as kse is functional on > the tier-1 platforms. > I'm with you until this point. THR provides the competition to keep KSE moving. As long at it has an active maintainer, I can't see it being removed. Scott