From owner-freebsd-threads@FreeBSD.ORG  Fri May 30 16:58:59 2003
Return-Path: <owner-freebsd-threads@FreeBSD.ORG>
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 212A337B401; Fri, 30 May 2003 16:58:59 -0700 (PDT)
Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 6AA5643F3F; Fri, 30 May 2003 16:58:58 -0700 (PDT)
	(envelope-from eischen@pcnet.com)
Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4])
	by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h4UNwvNc012328;
	Fri, 30 May 2003 19:58:57 -0400 (EDT)
Date: Fri, 30 May 2003 19:58:57 -0400 (EDT)
From: Daniel Eischen <eischen@pcnet.com>
To: ports@freebsd.org
Message-ID: <Pine.GSO.4.10.10305301945590.10348-100000@pcnet5.pcnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: threads@freebsd.org
Subject: Transition plans: libkse->libpthread
X-BeenThere: freebsd-threads@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Threading on FreeBSD <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 30 May 2003 23:58:59 -0000

Sometime shortly after 5.1 release, we'll (hopefully) be
installing libpthread as "libpthread" instead of "libkse"
by default.  There are some things that need to be fixed
(signal handling) before this can happen, but we're working
on it now.

Locally, I install the library as libpthread, but this
breaks lots of ports that use autoconf and/or libtool.  I
still have PTHREAD_LIBS unchanged (set to libc_r), but
that doesn't seem to matter.

What happens is that some things end up getting linked to
both libpthread and libc_r, and compiler wackiness ensues
also.  To see what happens, try:

  # cp /usr/lib/libkse.so.1 /usr/lib/libpthread.so.1
  # ln -s /usr/lib/libpthread.so.1 /usr/lib/libpthread.so

and then rebuilding XFree86-4 and kde3.1.

I suspect that we want PTHREAD_LIBS to always be obeyed,
so that one could link to libc_r, libthr, or libpthread.
Sure, one could use libmap, but applications that are
linked to different threading libraries should be able
to coexist.

Anyway, this is just to give you guys some advance notice
of future breakage.

-- 
Dan Eischen