sasjfp@unx.sas.com (Jeffrey L. Phillips) (08/29/90)
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 <sys/mbuf.h> 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.comced@apollo.HP.COM (Carl Davidson) (08/29/90)
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 <sys/mbuf.h> 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 <sys/mbuf.h> 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
krowitz@RICHTER.MIT.EDU (David Krowitz) (08/29/90)
Hah! Missing Unix include files ... try the Aegis /sys/ins files that keep having new mistakes introduced in them at every minor OS release! As usual, HP/Apollo's response is something along the lines of "Well, when OSF is released, you won't want to use those insert files anyway (BSD and Aegis)" We've been getting that sort of encouragement for the past two years. OSF will be out in about 6 months, by my guess; and it will be SYSV compliant according to all the literature. HP/Apollo has said nothing about BSD compliance nor whether they will port any of the Apollo specific libraries to OSF. Here's a simple question in economics ... if company A has to support HP/UX, Aegis, BSD, SYSV, and OSF and if company B only has to support a SYSV derivative, who has the better profit margin? If company A says that OSF is "the standard", how much effort will they put into the other 4 OS releases, and how much effort will they put into forcing (ahem, I meant to say "encouraging") their customer base into adopting the "standard" OS? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
turner@smart.sps.mot.com (Robert Turner) (08/29/90)
Gnu-make, a far better make program than standard UNIX make, ports to the Apollo with the supplied makefile with no problems. Robert -- Law of the Net: Trivia begets trivia tenfold. All opinions are. Robert Turner (602) 897-5441 ...!uunet!dover!turner or turner@dover.sps.mot.com Semiconductor Systems Design Technology, Motorola USnail: 2100 E. Elliot Rd., MD: EL510, Tempe, Az 85284-1801
chen@digital.sps.mot.com (Jinfu Chen) (08/29/90)
In article <4c7aae64.20b6d@apollo.HP.COM> ced@apollo.HP.COM (Carl Davidson) writes: >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. I tend to agree with Carl for pulling programs off net and compiling without too much problem in SR10.x. However, every once a while I'd encounter a program using some include files that I can't find. For examlpe, nntp is one. Most of time I could get one from a Sun system and hack around some equivalent code but that's still extra efforts. Although the latest release has some #ifdef apollo lines to get around the missing <sys/vfs.h> file which apparantly is available in, according to cpp symbols, sun, hpux, pyr, hp300, and NeXT, it's still annoying to see Apollo sits out off the majority. Since I am not a BSD expert but an avid BSD user, I don't know how compatible Domain/OS BSD4.3 to the "real" BSD4.3. If there is a BSD 4.3 comformance test suite, like the SYS V3 test suite, I hope Apollo could pass it. >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? Perhaps another way is to have some HP/Apollo people who are BSD fans, such as Carl, to push from inside. User community will benifit from it. Of course, we could all wait for OSF/1 :-) -- Jinfu Chen (602)898-5338 Motorola, Inc. SPS Mesa, AZ ...uunet!motsps!digital!chen chen@digital.sps.mot.com CMS: RXFR30 at MESAVM ----------