From owner-freebsd-questions Sun Sep 21 16:56:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA25858 for questions-outgoing; Sun, 21 Sep 1997 16:56:05 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA25826 for ; Sun, 21 Sep 1997 16:55:57 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id JAA08913; Mon, 22 Sep 1997 09:25:46 +0930 (CST) Message-ID: <19970922092546.21646@lemis.com> Date: Mon, 22 Sep 1997 09:25:46 +0930 From: Greg Lehey To: Brad Hendrickse Cc: FreeBSD-Questions Subject: Re: Make world: error code 140 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: ; from Brad Hendrickse on Mon, Sep 22, 1997 at 12:35:55AM +0200 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Sep 22, 1997 at 12:35:55AM +0200, Brad Hendrickse wrote: > >> uudecode < /usr/src/share/tabset/zenith29.uu >> ===> share termcap >> ex - /usr/src/share/termcap/termcap.src < >> /usr/src/share/termcap/reorder > /dev/null (That's not how it's >> wrapped. This tries to be on one line.) >> Bad system call - core dumped >> ***Error code 140 > Hi there, the problem mailed by Greg below is the same problem I'm > having. I was awaiting a reply to Greg's message, but thus far have not > noticed a reply to him. Possibly the reply was mailed directly to him. > I've tried running: > > ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder > > /dev/null > > which then runs fine. Thus far it's happened with -CURRENT and > 970807-SNAP, AFAIK. Yes, I've had exactly this problem, and I've also noticed that it doesn't happen if you do it directly in the termcap directory. It seems to be a bit of a chicken-and-egg problem. In my case, I was upgrading an old (December 1996) version of 3.0-CURRENT. The 'bad system call' signal means that the program has issued a system call that the kernel doesn't understand. In many cases, this is the result of a bug in the program, but in this case it's because the old kernel doesn't understand the new system call. The solution I found was to build and install a kernel, then restart the 'make world' with -DNOCLEAN (to speed things up a bit). Greg