kahn@wucs1.wustl.edu (Michael Kahn) (12/15/90)
The version of CAP from Rutgers does not compile on the NeXT. I know in the past that Ed Moy had a set of mods he created for the version of CAP on SUMEX that worked for me about 1 year ago, but alas, CAP no longer is on SUMEX. Some of Ed's modifications apparently are still in the Rutger's distribution (ie, Configure accepts 'next' as a known machine configuration), but the distribution doesn't seem to do the right thing in the Configure script (nm doesn't find any names in the /lib/libc.a) which I think sets up to error seen during compilation (cannot find file 'unistd.h'). Any ideas why the Rutgers upgrades have broken Ed's NeXT's mods? Michael Kahn (kahn@informatics.WUSTL.EDU)
rapatel@pilot.njin.net ( Rakesh Patel) (12/16/90)
We did test it and get it running on the NeXT (after making some minor changes including the problem with 'unistd.h'). I thought I had updated the ftp area. I just made sure that the latest version is on rutgers.edu. Rakeh Patel.
edmoy@violet.berkeley.edu (12/18/90)
In article <1990Dec15.130100.18666@cec1.wustl.edu> kahn@wucs1.wustl.edu (Michael Kahn) writes: >The version of CAP from Rutgers does not compile on the NeXT. I know >in the past that Ed Moy had a set of mods he created for the version >of CAP on SUMEX that worked for me about 1 year ago, but alas, CAP no >longer is on SUMEX. Some of Ed's modifications apparently are still >in the Rutger's distribution (ie, Configure accepts 'next' as a known >machine configuration), but the distribution doesn't seem to do the >right thing in the Configure script (nm doesn't find any names in the >/lib/libc.a) which I think sets up to error seen during compilation >(cannot find file 'unistd.h'). > >Any ideas why the Rutgers upgrades have broken Ed's NeXT's mods? > >Michael Kahn >(kahn@informatics.WUSTL.EDU) I can't say about the Rutgers code and NeXT 1.x, but if your running NeXT 2.0, then there are new fixes that need to be made for all versions of CAP. 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). 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
edmoy@violet.berkeley.edu (12/19/90)
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