Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!unmvax!uokmax!servalan!rmtodd From: rmtodd@servalan.uucp (Richard Todd) Newsgroups: comp.unix.aux Subject: Re: missing routine from A/UX library? Keywords: rewinddir Message-ID: <1991Jun19.231832.18164@servalan.uucp> Date: 19 Jun 91 23:18:32 GMT References: <453@aplcomm.JHUAPL.EDU> Organization: Ministry of Silly Walks Lines: 41 beser@aplcomm.JHUAPL.EDU (Nick Beser) writes: >#include >#include >however, when linking the program, the linker states that rewinddir is >missing. The man page on rewinddir suggests that #include is >ok to use. Any Ideas what could be going on? By substituting Yeah. The problem is that rewinddir is actually a macro, not a function, and it's defined in sys/dir.h (which is included by dirent.h, so the two are equivalent)---however, it's defined inside of a maze of Stupid Apple Ifdefs. Actually, there are two problems--#1, that the Apple include files are a twisty turny maze of Stupid Preprocessor Tricks such that most programs won't compile unless the _SYSV_SOURCE and _BSD_SOURCE preprocessor macros are defined, and #2, while cc by default *does* turn on those preprocessor flags, gcc does not. You can either fix gcc to turn these on by default (it's a fairly simple patch to config/tm-aux.h in the GCC source), or stick -D_SYSV_SOURCE -D_BSD_SOURCE in the CFLAGS line in the Makefile. >#include I get it to link, however the program bombs >as soon as it runs. The first time I run it from the window, I get >an openning of the xxgdb window, but the program exits right away. >If I try it again, it just returns without openning a window at all. Ah. This sounds like the dreaded 4.2-signal problem (programs that expect 4.[23]BSD signal semantics failing catastrophically on A/UX, where the default is SysV signal semantics). Stick a call to "set42sig()" at the beginning of the main function. >Has anyone been successfull in getting xxgdb operating on A/UX? Well, I haven't :-(. The problem I ran into was that when you issue a gdb command, the gdb subprocess goes into an infinite loop, printing its prompt over and over. I didn't have time to look into exactly why it does this, so I gave up on it. If you figure out what the problem is, let us all know :-). -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp "We're thinking about upgrading from SunOS 4.1.1 to SunOS 3.5."--Henry Spencer