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
#include                                   jrw@mtune.att.com