From owner-freebsd-current@FreeBSD.ORG  Fri Feb 20 11:50:57 2004
Return-Path: <owner-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 8A8A716A4CE
	for <current@freebsd.org>; Fri, 20 Feb 2004 11:50:57 -0800 (PST)
Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 42D4A43D39
	for <current@freebsd.org>; Fri, 20 Feb 2004 11:50:57 -0800 (PST)
	(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 i1KJouSQ023864;
	Fri, 20 Feb 2004 14:50:56 -0500 (EST)
Date: Fri, 20 Feb 2004 14:50:56 -0500 (EST)
From: Daniel Eischen <eischen@vigrid.com>
X-Sender: eischen@pcnet5.pcnet.com
To: Doug White <dwhite@gumbysoft.com>
In-Reply-To: <20040220101615.U60703@carver.gumbysoft.com>
Message-ID: <Pine.GSO.4.10.10402201448220.19728-100000@pcnet5.pcnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: current@freebsd.org
Subject: Re: openldap server + kse = bewm
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Feb 2004 19:50:57 -0000

On Fri, 20 Feb 2004, Doug White wrote:

> On Fri, 20 Feb 2004, Daniel Eischen wrote:
> 
> > > no change in status.
> > >
> > > Here's the trace from gdb:
> >
> > This doesn't show much to me...
> 
> As to the libc thing, I'm assuming its getting picked up as a dependency
> on something else.  I'll check the build to make sure it isn't getting
> requested explicitly.
> 
> Since the libc pthread_mutex_lock() immediately calls the libpthread one,
> I assumed it was some sort of stub function.

Yes, but it shouldn't be calling the libc function if it is
linked in the correct order.  There are all sorts of symbols
that libpthread provides that should be resolved first
(cancellation points for instance).  If libc is being
linked to before libpthread, all bets are off for whether
the application behaves correctly.

-- 
Dan Eischen