From owner-freebsd-current  Thu Jan 13  3:53:32 2000
Delivered-To: freebsd-current@freebsd.org
Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9E8C215090; Thu, 13 Jan 2000 03:53:29 -0800 (PST)
	(envelope-from eischen@vigrid.com)
Received: (from eischen@localhost)
	by pcnet1.pcnet.com (8.8.7/PCNet) id GAA02549;
	Thu, 13 Jan 2000 06:53:25 -0500 (EST)
Date: Thu, 13 Jan 2000 06:53:25 -0500 (EST)
From: Daniel Eischen <eischen@vigrid.com>
To: "David O'Brien" <obrien@FreeBSD.ORG>
Cc: jasone@canonware.com, current@FreeBSD.ORG
Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp.
In-Reply-To: <20000112211625.A21988@dragon.nuxi.com>
Message-ID: <Pine.SUN.3.91.1000113063740.1076A-100000@pcnet1.pcnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, 12 Jan 2000, David O'Brien wrote:

> On Wed, Jan 12, 2000 at 07:00:01PM -0800, John Polstra wrote:
> > > The buildworld problem that I introduced is due to cc_fbsd directly
> > > compiling and linking in src/lib/libc/stdio/mktemp.c.  This is in my
> > > opinion a questionable practice, since it adds dependencies to the
> > > internals of the libc code, which has just been proven to bite. =)
> > 
> > Yes, I agree.
> 
> I disagree.  :-)
> I don't see why a plain function like mkstemp() should be written so
> specially.  Couldn't all the hiding/changing done for threads be done
> w/in open() itself?  Neither HP-UX 10.30 (which has kernel threads), nor
> Solaris 7 needs such open() hackery in mkstemp().

Given where we want to go with pthreads, and the proposed architecture,
I'm not sure why we need to have open -> _libc_open -> __open (or
whatever it is).  Why isn't using _open internally in libc sufficient?
open is a weak symbol for _open, and libpthread can override the open
(weak symbol).

Trying to make a libpthread out of libc_r which is hopefully near
its end of life, doesn't seem worth the effort, IMHO.

Dan Eischen
eischen@vigrid.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message