Path: utzoo!utgpu!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!rutgers!ucla-cs!admin.cognet.ucla.edu!casey From: casey@admin.cognet.ucla.edu (Casey Leedom) Newsgroups: comp.sys.apollo Subject: Re: SR10: /usr/include/apollo/{base,time}.h and cc -A nansi ... Keywords: SR10, ANSI C, non ANSI C, Apollo include files Message-ID: <17748@shemp.CS.UCLA.EDU> Date: 10 Nov 88 08:42:25 GMT References: <17508@shemp.CS.UCLA.EDU> <3f749e82.d5b2@apollo.COM> Sender: news@CS.UCLA.EDU Reply-To: casey@cs.ucla.edu (Casey Leedom) Organization: UCLA Cognitive Science Program Lines: 113 As per a previous posting on the Apollo CPU architecture predefined defines, please excuse the delay in responding to the subject line. I've just been out to lunch with far too many things banging at my door. | From: oj@apollo.COM (Ellis Oliver Jones) | | | From: casey@cs.ucla.edu (Casey Leedom) | | | | The latest chapter in my endless quest to get X.V11R3 compiled on SR10 ... | | "Endless" for hundreds of megabytes of source code that's been out a | whole week? Doesn't sound endless to me. Sounds like a week's work. | :-) For a software system as portable as X11.3, that has had as much effort put into it to achieve that end, that compiles (if not runs) on so many systems with no modification, which has now taken two weeks to get going? (albeit I've been doing five or six other things simultaneously) But thanks for the smiley face, I appreciated it (no sarcasm). I've now been stopped since Friday when we ran into a small problem compiling the server: a bunch of missing functions ``font_$...''. A couple calls to Apollo narrowed these down to /lib/gmrlib. (I would have found it myself, but the SR9.7 4.2bsd nm(1) didn't print out the routine names when I used ``nm -g /lib/gmrlib | more'', I had to remove the "-g" flag, after which the routines showed up as global functions ...) It turns out that Apollo has unbundled their graphics development software with SR10. How wonderful. (More sarcasm than you can *possibly* imagine.) I now have a graphics workstation with no graphics development software. It was only $180, so we ordered it right away, but I'm staggeringly offended by this. I can't even imagine what brain damage was the cause of this farsighted decision. Long live customer support at Apollo! Currently we're trying out a number of options ranging from compiling the X11.3 server under SR9.7 to translating the SR9.7 gmrlib to COFF format. My feeling is that the only workable solution will probably be to use the new gmrlib. Note that Apollo has also changed the library extensively according to what I've been told, but they include an extensive set of instructions on how to convert your old code to use the new library. I'll let people know how much that helps as I try to convert the X11.3 Apollo server to use the new library. | | 1. Apparently ANSI C defines the sequence "##" to be interpreted by the C | | Preprocessor (cpp) as a null string which can be used to separate | | macro references... | | #define foo(a, b) a##b | | The Apollo SR10 compiler totally barfs on this. | | I've submitted an internal bug report on this point. Thanks. By the way | /**/ works fine. You'll probably get reasonable response by submitting | bug reports like this yourself, to the Customer Services department. Thanks for submitting the bug report. You're right (in a private letter) that I should be doing this myself. I'll continue to post those bugs reports however because it helps prevent others from wasting the same time and puts presure on the people back at the home office to get things like this fixed. As for /**/ working, that's fine. But I'm not going to go through the entire X11.3 distribution replacing occurrences of "##" with "/**/". The X distribution is *huge*. It's Apollo's bug, Apollo should fix it. The X developers did their best to make X11.3 as portable as they possibly could. They legitimately ifdef'ed all their code on __STDC__. Apollo illegitimately took it on themselves to define the symbol in their own NON-ANSI C compiler. Fix it. | >2. I was finally able to find something I could ifdef on to decide | > whether to try to include /sys/ins/base.ins.c or | > /usr/include/apollo/base.h - I used _BFMT__COFF. | | Yup. Good choice. It also works just fine if you use __STDC__ . Using | __STDC___ to decide which header files you want solves your next problem | too. No it doesn't. As I pointed out in a previous letter I can't use __STDC__ because Apollo doesn't really *have* an ANSI C compiler. If it did, I could. I have to use the -A nansi switch to work around the above "##" problem. | | 3. Continuing with Load.c, it turns out that base.h and time.h (and | | probably several other files in /usr/include/apollo) have ANSI C | | functional prototypes declared. They don't ifdef the external function | | declarations on __STDC__ even though it's available, properly | | implemented by the Apollo compiler, and specifically for this purpose. | | This shows up on many header files, such as . Some of them | could get awful big if we had to go both ways. Fix the compiler to be a true ANSI C compiler then and make damn sure it can handle *ALL* old C constructs. If you can't do that, then add the old C extern function declarations back into the header files ifdef'ed on __STDC__. If you can't handle the job, I'll send you the diffs. It's not that hard, and no, the files don't get that much bigger. I'd also like to thank Guy Harris for his, as usual, clear, concise, and to the point note on why Apollo should support the standard header files in /usr/include/netinet. If I can ever get X11.3 compiled, I can test the header files I put together (absolutely *NO* help from Apollo). I will be posting a complete description of how to get X11.3 up under SR10 on comp.windows.x. More thanks to Paul 'da Kingfish for his suggestion of adding an OS predefine (e.g.SR10_0). My fixes will probably include instructions for adding this to . Probably something along the line of: #define SR10_0 1 /* SR10.0 */ #define APOLLO_OS_SR 1000 /* ver.rel -> 100*ver + rel */ Casey