Path: utzoo!attcan!uunet!ginosko!rex!ukma!rutgers!dptg!mtune!jrw From: jrw@mtune.ATT.COM (Jim Webb) Newsgroups: comp.sys.att Subject: Re: mkdir missing from libc.a Summary: syscall interface Message-ID: <8057@mtune.ATT.COM> Date: 10 Aug 89 17:33:17 GMT References: <475@mccc.UUCP> <1160@vsi.COM> Distribution: na Organization: AT&T ISL Middletown NJ USA Lines: 38 In article <1160@vsi.COM>, friedl@vsi.COM (Stephen J. Friedl) writes: > In article <475@mccc.UUCP>, pjh@mccc.UUCP (Pete Holsberg) writes: > > > > My SV R3.0 Programmer's Reference manual lists mkdir(2) as an available > > system call, but ar -t libc.a shows that mkdir.o is not there. What > > does this mean? > > and see what the message is. If you've an old compiler, you can > get a new compiler (CPLU4.2 is the latest), write wrapper functions > in assembler, or borrow mkdir.o from somebody's current libc.a. If you don't want to trade up to the CPLU4.2 compiler (which *is* fantastic, I might add, too) you can access any system call via the syscall() routine. I don't know where (if?) it is documented, but it takes the internal number of the system call and then the system call's arguments. So, to do a mkdir, you could do: #define MKDIR 80 mymkdir(path,mode) char *path; int mode { return(syscall(MKDIR,path,mode)); } Now, finding out what the system call number is easy when you have kernel source, but a bit more fun to find if you don't. Suffice it to say it is 80 for any System V style release. Now, I **agree** this is messy, no doubt about it, but it does get the job done. Happy hacking.... -- Jim Webb "Out of Phase -- Get Help" att!mtune!jrw #includejrw@mtune.att.com