From owner-freebsd-current Wed Jan 19 8:15:59 2000 Delivered-To: freebsd-current@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 0E0CD152D0 for ; Wed, 19 Jan 2000 08:15:57 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 38559 invoked by uid 1001); 19 Jan 2000 16:14:40 -0000 Date: Wed, 19 Jan 2000 08:14:39 -0800 From: Jason Evans To: David O'Brien Cc: current@FreeBSD.ORG Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp. Message-ID: <20000119081439.K27689@sturm.canonware.com> References: <20000112211625.A21988@dragon.nuxi.com> <20000119013643.A36827@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000119013643.A36827@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Wed, Jan 19, 2000 at 01:36:43AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 19, 2000 at 01:36:43AM -0800, David O'Brien wrote: > On Thu, Jan 13, 2000 at 06:53:25AM -0500, Daniel Eischen wrote: > > On Wed, 12 Jan 2000, David O'Brien wrote: > > > 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). > > Is this email being ignored? No, I was just busy doing other things. There is potentially one good reason to leave these changes in place for now: they allow proper thread cancellation in libc_r as it stands right now. This seems to me like a good enough reason to leave the changes as is until our grand new threads library is realized. However, I agree that in the end we will want to simplify the libc symbol naming. I'm planning on checking in libc_r cancellation changes today that use the current libc symbol naming setup. As soon as we're not using libc_r anymore I'll be glad to simplify the symbol naming. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message