From owner-freebsd-threads@FreeBSD.ORG Fri Feb 6 12:37:08 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89F2316A4CE for ; Fri, 6 Feb 2004 12:37:08 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B52D843D69 for ; Fri, 6 Feb 2004 12:36:44 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 60ADB72DBF; Fri, 6 Feb 2004 12:36:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5C48C72DB5 for ; Fri, 6 Feb 2004 12:36:43 -0800 (PST) Date: Fri, 6 Feb 2004 12:36:43 -0800 (PST) From: Doug White To: freebsd-threads@freebsd.org Message-ID: <20040206122906.N16801@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: thread mixups in kde/qt X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2004 20:37:08 -0000 This is a blind post, mostly for the benefit of the archives (and krion :-) ) since I ran across it in the past couple of days. If you're getting the "Spinlock called when not threaded." message, its definitely mixed libraries, usually libc_r and pthread. What may not be obvious is where they're coming from in the case of kde & qt. The qt port uses it own form of libtool called qmake. Qmake contains library link instructions for the platform. If you haven't rebuilt qmake since the pthread change, it is probably still offering -lc_r to qt, and this causes the duplicate dependency when qt gets built. For me, the kdelibs3 port trips over the dependency when it tries to run an intermediary build tool that links against qt, called dcopidl. Running it without arguments will trigger the assertion. I was able to build it with debugging last night, and looking at the backtrace tipped me off that a library dependency was to blame. In general, I've found something like this to help find where libc_r dependencies are coming from: objdump -x `ldd /path/to/bad/program | awk ' { print $3 }'` | less Look for occurances of 'libc_r', then see what library they're coming from, then rebuild the offenders. As mentioned previously, you can hack around it with libmap until you can get the older stuff rebuilt. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org