From owner-freebsd-current@FreeBSD.ORG Wed Aug 2 20:13:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org 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 8F72416A4E5 for ; Wed, 2 Aug 2006 20:13:36 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5309343D58 for ; Wed, 2 Aug 2006 20:13:35 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k72KDYUq009459; Wed, 2 Aug 2006 16:13:34 -0400 (EDT) Date: Wed, 2 Aug 2006 16:13:34 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Birrell In-Reply-To: <20060802194817.GA53062@what-creek.com> Message-ID: References: <1154527524.93666.22.camel@tobias.home.web-wahnsinn.de> <20060802194817.GA53062@what-creek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-current@freebsd.org, Tobias Gro?er Subject: Re: DTRACE build failure (/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 02 Aug 2006 20:13:36 -0000 On Wed, 2 Aug 2006, John Birrell wrote: > On Wed, Aug 02, 2006 at 04:05:24PM +0200, Tobias Gro?er wrote: >> >> Unfortunally I am not able to finish the build because it always breaks >> in /usr/src/cddl/usr.bin/ctfconvert with this ld-error: >> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lpthread > > Sorry. At the moment the dtrace project has an experimental implementation of > threads merged into libc and you need to enable this by adding WITH_LIBC_THREADS=1 > to /etc/make.conf. Then it will build. > > Also, since the KSE code in the kernel doesn't handle signals properly in a > many-cpu system, in order to make progress on sun4v, the KSE code has been > removed. We really need to try to make it a kernel option so that we can compare > the thread implementations. Making KSE a kernel option is very messy, though. KSE doesn't yet work on sparc64, which is why libc_r and libthr are used for that platform. -- DE