Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!psuvax1!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!ced From: ced@apollo.HP.COM (Carl Davidson) Newsgroups: comp.sys.apollo Subject: Re: Skeleton include files Message-ID: <4c7aae64.20b6d@apollo.HP.COM> Date: 29 Aug 90 01:07:00 GMT References: <1990Aug28.204058.17366@unx.sas.com> Sender: root@apollo.HP.COM Distribution: usa Lines: 100 From article <1990Aug28.204058.17366@unx.sas.com>, by sasjfp@unx.sas.com (Jeffrey L. Phillips): > Has anyone noticed any problems with Apollo's include files. It seems like I > have never been able to pull any sources, etc. off the net and have them > complile. Sometimes I can 'tweek' a few things and get them to work, but most > things I cannot get to compile at all. > > Gated, for instance, will not compile on Apollo (version 2.0) because a > 'standard' include file was decided not to be included on Apollos. > Every other system I have looked at around our company has this include file > except for Apollo. > > When I confronted Apollo about this gated problem, they shrugged it off by > reminding me that gated was in domain_examples and they don't support it > anyway. When I pressed them on the issue of include files in general, I was > told that they were sorry to hear about it, but that was about it. > > I'm using bsd 4.3 include files because I want some portability with my > programs. Besides, I get tired of typing '_$'s all the time with Apollo calls. > > Has anyone else out there had as much frustration with include files, or am I > just an idiot? ;-) > -- > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > "Just because I don't know what it means doesn't mean I'm lying." > > Jeff Phillips Email: sasjfp@dev.sas.com Jeff, what version of Domain/OS are you running? I ask because like you I am a confirmed 4.3bsd user because of the portability aspect, not only of code, but of user skills. In the last three years (since we began running SR10 and its descendents here in Chelmsford) I've ported several programs "right off the net" without any trouble at all: Mush (versions 5.7, 6.0, 6.1, 7.0, and now 7.1), VN, GWM, mkmf, arc 5.21, cpr, and rolo, just to name a few. In general, the sources compiled, linked, and run with no modification. Occasionally I've had the odd problem with the fact that our C compiler is pickier than most about not abusing pointers and such, but I don't recall ever having a problem with include files. Makefiles, on the other hand, can be a pain occasionally. For example, the GWM makefile was such a bother that I decided it was easier to let mkmf create a new Makefile from scratch and them to touch it up to get the lex and yacc rules right (mkmf doesn't purport to get all that stuff just right). As for gated, even if we had shipped you wouldn't have been able to build and use it because gated is one of those programs that insists on munging around in /dev/kmem, and Domain/OS doesn't have any such animal. That doesn't mean you're entirely out of luck, however. At SR10.3, we ship modified sources for gated as unsupported software in /domain_examples, as our Response Center. These modified sources make use of a new IOCTL called SIOCGRTTAB (something like SocketIOCtlGetRouTingTABle, I believe) which allows you to get at the routing table without having to munge around in the kernel through /dev/kmem or the like. The sources include a Makefile which will enable you to build a working gated on SR10.3. Programs that want to access /dev/kmem aside, I've never had a serious problem porting user-space code that runs on any other 4.3bsd-based system. That's not to say that we're perfect, because, of course Domain/OS isn't perfect. What might be interesting would be to ask other readers of comp.sys.apollo to give us the benefit of their accumulated wisdom regarding porting code gleaned from comp.sources.unix and alt.sources to Domain/OS. I'm sure there are folks out there with a significant bag of tricks that we could all benefit from. How about it, folks? By the way, I feel the need for two disclaimers that I don't include in my .signature file because we're running some silly posting software here that won't let your .signature file be more than 4 lines long: 1. The opinions expressed here are (to paraphrase Daffy Duck) "Mine! Mine! All Mine!" They are not those of The Hewlett-Packard Company, its Apollo Systems Division, or anybody else around here but me. You have to get those from John Young, Bill Kay, Dave Perozek, or some PR hack. 2. I build my stuff off the net with the same compilers, tools (make, etc.), and include files that we ship to customers. I don't use any special stuff that we have here but don't release to customers. I don't have to. The stuff we ship works just fine, thanks (oops, there goes another one of those damned opinions). Thanks for listening to me ramble and keep those cards and letters coming. Regards, Carl P.S. Somebody told me the other day that they didn't think that folks could send me email through the apollo.hp.com Domain address in my .signature because it wuldn't get here through the HP internal network. I don't think that's true, but if you've tried to send me hate mail and it's been bounced somewhere, try sending it again, but this time try ced@apollo.com. Our link through MIT is still up, I think and it shouldn't bounce through there. Long term, though, I think that link will go away, so I put the "official" one in my .signature. Bye! Carl Davidson (508) 256-6600 x4361 | In the High and Far-Off Time, the The Apollo Systems Divison of | Elephant, Oh Best Beloved, had no The Hewlett-Packard Company | trunk. DOMAIN: ced@apollo.HP.COM | -- Rudyard Kipling, Just So Stories