friedl@vsi.UUCP (Stephen J. Friedl) (04/13/88)
In article <568@mccc.UUCP>, pjh@mccc.UUCP (Peter J. Holsberg) writes: > I'm trying to compile the latest rzszzm stuff, but ran into the following: > > undefined first referenced > symbol in file > mkdir rz.o > ld fatal: Symbol referencing errors. No output written to rz > > My SysVr3 Programmer's Reference Manual has a nice description of > mkdir(2), so I don't understand what's causing the error. Is my > interpretation -- ld can't find a function called mkdir in its libraries > -- correct? The kernel has it but your PCC2 (or C Issue 3) libraries don't have the little gateway functions. Your long-term fix is to get the latest compilers to get the library that contains them. A short-term hack is to do: $ cat > mkdir.s .globl mkdir .globl _cerror mkdir: MOVW &4,%r0 MOVW &0x280,%r1 GATE BGEUB noerror JMP _cerror noerror:RET ^D $ as mkdir.s Now include "mkdir.o" in your compile lines. The other SVR3-specific functions in the C library work the same way, but not all of them have "quick-and-dirty" interfaces (signal stuff is ugly). -- Steve Friedl V-Systems, Inc. "Yes, I'm jeff@unh's brother" friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl
pjh@mccc.UUCP (Peter J. Holsberg) (04/14/88)
In article <527@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes: == In article <568@mccc.UUCP>, pjh@mccc.UUCP (Peter J. Holsberg) writes: == > mkdir(2), so I don't understand what's causing the error. Is my == > interpretation -- ld can't find a function called mkdir in its libraries == > -- correct? == == The kernel has it but your PCC2 (or C Issue 3) libraries don't == have the little gateway functions. Your long-term fix is to get == the latest compilers to get the library that contains them. == Thanks, Steve. Perusal of /usr/names shows this: C-FP+ Issue 1 Version 0 C Programming Support I2 V0 SGU I3 V2 FP Library I1 V0 SysVr3.1 is on its way. Perhaps things will be aligned a bit better then. OTW, a call to my local AT&T person will be in order. -- Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh Technology Division CompuServe: 70240,334 Mercer College GEnie: PJHOLSBERG Trenton, NJ 08690 Voice: 1-609-586-4800
martin@mwtech.UUCP (Martin Weitzel) (06/30/91)
In article <2751@root44.co.uk> gwc@root.co.uk (Geoff Clare) writes: >tom@itc.univie.ac.at (Tom Kovar) writes: > >> The superuser may generate directory hard links (see >>link(2v)); if not, it would not be possible to have the . and .. entries >>in the directory :-) > >Not true. The links to . and .. can be created by a mkdir() system call, >in which case there is no need for link() to be able to link directories. There is no mkdir(2) system call in some older variants of UNIX. (I think it was not in V7 and probably also not in SysIII, though some companies who used SysIII as porting base might have added it; I don't know about BSD either.) If a system doesn't have mkdir(2), there surely IS a need that link(2) can link directories, though there are some nasty race conditions with this technique which open a (admittedly difficult to exploit) security hole. Of course, one may go as far to suggest that a mkdir(2) system call SHOULD rather be implemented than allowing to link directories with link(2) - and I would second that for said security problems - but there EXIST versions of UNIX in which it would NOT be possible to create the . and .. entries in a directory if it could not be done with link(2). -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
torek@elf.ee.lbl.gov (Chris Torek) (06/30/91)
In article <1175@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >There is no mkdir(2) system call in some older variants of UNIX. (I think >it was not in V7 and probably also not in SysIII, though some companies >who used SysIII as porting base might have added it; I don't know about >BSD either.) The mkdir system call (not to be confused with the mkdir program) first appeared in 4.2BSD.% It was not added to System V until recently; the exact date depends on whose `System V' you use (consider it nonstandard). ----- % It may have been in 4.1a, 4.1b, or 4.1c, but it was not in 4.1 and none of the others were widely released. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov