From owner-freebsd-current Wed Oct 29 05:28:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA15485 for current-outgoing; Wed, 29 Oct 1997 05:28:45 -0800 (PST) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA15480 for ; Wed, 29 Oct 1997 05:28:42 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id AAA14486; Thu, 30 Oct 1997 00:23:29 +1100 Date: Thu, 30 Oct 1997 00:23:29 +1100 From: Bruce Evans Message-Id: <199710291323.AAA14486@godzilla.zeta.org.au> To: asami@cs.berkeley.edu, gurney_j@efn.org Subject: Re: bad system call - world build Cc: freebsd-current@freefall.FreeBSD.org, peter@spinner.netplex.com.au Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> This is what I know about the "make world" problem: >> >> (1) It only breaks on some programs, most notably vi during termcap >> compilation. There should be some other programs before vi that >> use getcwd(), I wonder why they don't die. >... >I looked at the diffs between 2.2.1 and 2.2.5, and it looks like the >call that we might be hitting is the new issuid... I KNOW that this I thought this was well known. getcwd() is a library function with a standard interface, so incompatibilities are easy to avoid, and are avoided. issetugid() is a syscall with a new interface. It can't possibly work with old kernels. Unfortunately, ex(1) uses it, at least for the termcap script. It is surprising that it isn't used more for `make world', since it is sometimes called by setlocale(). Bruce