From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 19:06:39 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 A1D1C16A4B3; Sat, 20 Sep 2003 19:06:39 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DF5B43FF7; Sat, 20 Sep 2003 19:06:38 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p1/8.12.3) with ESMTP id h8L26OGA018356; Sat, 20 Sep 2003 20:06:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 20 Sep 2003 20:06:25 -0600 (MDT) Message-Id: <20030920.200625.39876120.imp@bsdimp.com> To: jb@cimlogic.com.au From: "M. Warner Losh" In-Reply-To: <20030921015927.GA28195@freebsd1.cimlogic.com.au> References: <20030920.190533.63048335.imp@bsdimp.com> <20030921015927.GA28195@freebsd1.cimlogic.com.au> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: deischen@freebsd.org cc: h@schmalzbauer.de cc: current@freebsd.org Subject: 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 02:06:39 -0000 In message: <20030921015927.GA28195@freebsd1.cimlogic.com.au> John Birrell writes: : On Sat, Sep 20, 2003 at 07:05:33PM -0600, M. Warner Losh wrote: : > Why does -pthread necessarily force selection of one specific : > threading library? All it means is that it is that the program uses : > posix threads, at least traditionally. How FreeBSD causes that to : > happen is an interesting implementation detail for some, but irrelvant : > for most ports. Couldn't -pthread be made to give the user the : > default threading package, and for those that matter a more specific : > one can be specified? : : This subject *has* been discussed both within FreeBSD and with the GCC : maintainers. I think that the consensus from those who chose to participate : in that discussion was that -pthread would be a noop on FreeBSD. But it was completely removed. That sounds like the consensus wasn't followed. Why was it then removed? : > It is insane to have FreeBSD be different than all other systems for : > this trivial reason. Why fix everthing in the world when allowing : > -pthread to be a noop would solve the problem? Seems like we're being : > overly picky for no real gain. I guess I just don't understand. : : Having -pthread as a noop doesn't fix the ports breakage. For years ports : have worked on the basis that libc_r was linked to get user-space threads : *instead* of libc. This was the result of certain people in the FreeBSD : developer community not wanting thread stubs in libc. Since libc was : linked by default (unless -nostdlib was specified), it was necessary to : have gcc know to use libc_r instead. That is why the -pthread argument : was added. FWIW, Linux and the other BSDs didn't have a -pthread argument : back then. So we change -pthread to mean "link in the default threading package, with whatever magic is necessary for that package" rather than "link in libc_r instead of libc". : Now that libc has thread stubs in libc (in current), there is no longer : any need to have gcc know about any of the thread libraries. That's a : good thing IMO. The FSF wants GCC to have a -pthread argument on all : platforms and they are happy to have it as a noop. Then why was it completely removed? : I doubt that there would ever be a good time to make this change. The fact : that 4.9 has been delayed is making the problem seem worse because people : can't commit fixes to the tree. While 4.9 is delayed (due to the PAE : instability which never should have been allowed), the ports tree should : be unlocked. The fixes are simple. Make them and move on. At the very least, we should put it back as a noop. The timing on this really sucks because it breaks the ports tree for an extended period of time. While the fixes are simple, they haven't been made yet. The fact that the tree is frozen makes it seem like a really bad time to make the change. Warner