Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!swrinde!ucsd!ucbvax!agate!violet.berkeley.edu!edmoy
From: edmoy@violet.berkeley.edu
Newsgroups: comp.protocols.appletalk
Subject: Re: CAP on NeXT
Message-ID: <1990Dec18.185156.13496@agate.berkeley.edu>
Date: 18 Dec 90 18:51:56 GMT
References: <1990Dec15.130100.18666@cec1.wustl.edu> <1990Dec17.181005.13793@agate.berkeley.edu>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: University of California, Berkeley
Lines: 38

I've found another problem with CAP and NeXT 2.0, so I include my original
two fixes and add a third:

1) Before running Configure:

	# ln -s /lib/libsys_s.a /lib/libc.a

Yes, NeXT no longer distribute a libc.a as such, since they now do a runtime
library linkage.  Since Configure only looks for the existance of routines,
and since libsys_s.a contains the glue code for all the standard routines,
this link satisfies Configure.

2) After running gen.makes, edit applications/aufs/makefile and remove the
-DUSEQUOTA flag from the OSDEFS variable.  If you look at <sys/quota.h>,
you'll see that it is ifdef'ed out for NeXT machines.  The official word
from NeXT is that NeXT 2.0 does NOT support quotas, even though the include
file and the system calls are there (there are also no manual pages).

3) lockf() doesn't seem to work; it always returns a negative number, implying
the file is locked.  To prevent CAP from using lockf, I edited (temporarily)
conf.func.lst and changed the line beginning with:

	N+-,FCNTLLOCKF,/usr/include/fcntl.h,lockf,

to

	N+-,FCNTLLOCKF,/usr/include/fcntl.h,Xlockf,

so it doesn't find lockf.  You can also define NOLOCKF in the lib/afp and
applications/aufs makefiles.

Edward Moy				Principal Programmer - Macintosh & Unix
Workstation Support Services		Workstation Software Support Group
University of California
Berkeley, CA  94720

edmoy@violet.Berkeley.EDU
ucbvax!violet!edmoy