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. Message-ID: <Pine.SUN.3.91.1000113063740.1076A-100000@pcnet1.pcnet.com> In-Reply-To: <20000112211625.A21988@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1000113063740.1076A-100000>