From owner-freebsd-current@FreeBSD.ORG Sat Sep 20 22:02:31 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 35C9216A4B3 for ; Sat, 20 Sep 2003 22:02:31 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FCF843FAF for ; Sat, 20 Sep 2003 22:02:30 -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 h8L52IgG000703; Sun, 21 Sep 2003 01:02:18 -0400 (EDT) Date: Sun, 21 Sep 2003 01:02:18 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: "M. Warner Losh" In-Reply-To: <20030920.200625.39876120.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: h@schmalzbauer.de 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 05:02:31 -0000 On Sat, 20 Sep 2003, M. Warner Losh wrote: > 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? Consensus occured after further conversation with our FSF GCC maintainer. It doesn't matter now whether it is removed or NOOP'd; ports still break, but not as obviously. > : > 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". There is no default threading package. That's what PTHREAD_LIBS is suppose to do. If we assigned -pthread to one particular threading package, there would be no way to have a different one selected, except perhaps globally with /etc/libmap.conf. PTHREAD_LIBS allows the port builder to override (via /etc/make.conf) the default threading library with whatever they want. You can't do that with -pthread. > : 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? It doesn't matter; NOOP == 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. Again, whether it is a NOOP or removed, the same ports still break. It is possible that even more ports could break if it is NOOP'd; autoconf/configure can detect that -pthread is a valid switch if it doesn't emit an error. -- Dan Eischen