From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 16 16:17:45 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C52A16A4CE for ; Wed, 16 Jun 2004 16:17:45 +0000 (GMT) Received: from moutvdomng.kundenserver.de (moutvdom.kundenserver.de [212.227.126.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 396E543D4C for ; Wed, 16 Jun 2004 16:17:45 +0000 (GMT) (envelope-from liamfoy@sepulcrum.org) Received: from [212.227.126.224] (helo=mrvdomng.kundenserver.de) by moutvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 1Bad6P-0002wG-00; Wed, 16 Jun 2004 18:17:29 +0200 Received: from [81.154.134.17] (helo=Anarion) by mrvdomng.kundenserver.de with smtp (Exim 3.35 #1) id 1Bad6O-0008Ga-00; Wed, 16 Jun 2004 18:17:28 +0200 Date: Wed, 16 Jun 2004 17:17:24 +0100 From: Liam Foy To: Dan Nelson Message-Id: <20040616171724.0b8dfe26.liamfoy@sepulcrum.org> In-Reply-To: <20040616161338.GA7743@dan.emsphone.com> References: <20040616144127.0d92076d.liamfoy@sepulcrum.org> <20040616161338.GA7743@dan.emsphone.com> Organization: None X-Mailer: Sylpheed version 0.9.9 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org Subject: Re: libpthread problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jun 2004 16:17:45 -0000 On Wed, 16 Jun 2004 11:13:39 -0500 Dan Nelson wrote: > In the last episode (Jun 16), Liam Foy said: > > Hey guys, I seen to get this error on certain applications, such as > > xmms and beep-media-player: > > > > Fatal error 'Spinlock called when not threaded.' at line 83 in file /usr/src/lib/libpthread/thread/thr_spinlock.c (errno = 0) > > Segmentation fault (core dumped) > > That means that the program was linked with two threading libraries > (usually libc_r and libpthread), and unfortunately, they are not smart > enough to only initialize one or the other so they step on each others' > data. Run "ldd -a" on your binary, determine which file depends on > libc_r, and rebuild the port providing that file. > > A workaround would be to add a libmap.conf entry remapping libc_r to > libpthread globally. See the libmap.conf manpage for examples. > Thats great, I shall have a look into that. Is anyone working to try and solve this issue to do you know? > -- > Dan Nelson > dnelson@allantgroup.com -Liam J. Foy