pjh@mccc.UUCP (Pete Holsberg) (08/07/89)
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? Pete -- Pete Holsberg -- Mercer College -- Trenton, NJ 08690 ...!rutgers!princeton!njsmu!mccc!pjh
friedl@vsi.COM (Stephen J. Friedl) (08/10/89)
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? This comes up all the time. Unfortunately, AT&T's operating systems and C compilers are packaged separately, and while the OS supports mkdir as a system call, an old libc.a won't have the trivial wrapper function for it. C compilers releases 4.1 [no relationship to SVR4] and beyond all have the SVR3 stuff, while Issue 3, pcc2, and C-FP+ probably don't. You can find out your compiler type by cc -V 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 have 4.2, you're missing a phenomenal optimizer. Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / {attmail uunet}!vsi!{bang!}friedl / friedl@vsi.com "My new bestseller, _Teach_Yourself_to_Read_, is now available everywhere" -me
jrw@mtune.ATT.COM (Jim Webb) (08/11/89)
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 #include <std/disclaimer.h> jrw@mtune.att.com
friedl@vsi.COM (Stephen J. Friedl) (08/12/89)
[ discussion on how to get access to SVR3 system calls with an ] [ old compiler without the latest SVR3 libc.a. ] In article <8057@mtune.ATT.COM>, jrw@mtune.ATT.COM (Jim Webb) writes: > 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. One must be careful with syscall(). Most system calls (open, read, etc.) are just little wrapper functions in C that set up the parameters for the GATE assembly instruction, and syscall() is just a general-purpose interface for it. Not all system calls, however, are this simple, and you can't simply vector into the operating system this way. I don't have any kind of comprehensive list, but I believe that the entire signal() family -- one of the improvements with SVR3 -- has significant extra code that you don't get with syscall(). Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / {attmail uunet}!vsi!{bang!}friedl / friedl@vsi.com "My new bestseller, _Teach_Yourself_to_Read_, is now available everywhere" -me