casey@CS.UCLA.EDU (11/03/88)
The latest chapter in my endless quest to get X.V11R3 compiled on SR10. (Note that my partner in crime will be submitting a amusing little conversation he had with Apollo regarding the missing header files in /usr/include/netinet.) Several bugs really: 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 and allow their expansions to be concatenated properly. (Many older sources used the non-portable "/**/" equivalent.) Ex: #define foo(a, b) a##b The Apollo SR10 compiler totally barfs on this. Therefore I have to compile X.V11R3 with -A nansi. If the "##" construct is truly a part of Ansi C, can we get an update to Apollo's cpp that handles it properly? 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. I couldn't use __STDC__ for the above reason. So I have: #ifdef apollo #ifdef _BFMT__COFF #include <apollo/base.h> #include <apollo/time.h> #else #include "/sys/ins/base.ins.c" #include "/sys/ins/time.ins.c" #endif ... #endif In X.V11R3/lib/Xaw/Load.c. We really need something more along the lines of ``#ifdef SR10'' for this kind of thing however. 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. If people want, I will submit patches for these fixes. Can we get these installed in the standard Apollo release? Casey
casey@admin.cognet.ucla.edu (Casey Leedom) (11/04/88)
| From: Larry Allen <lwa@apollo.com> | | | From: Casey Leedom <casey@cs.ucla.edu> | | | | The latest chapter in my endless quest to get X.V11R3 compiled on SR10. | | (Note that my partner in crime will be submitting a amusing little | | conversation he had with Apollo regarding the missing header files in | | /usr/include/netinet.) | | It's very simple why we didn't ship all the "missing" header files in | <netinet/>: they're all internal kernel include files that aren't used | on Apollo (different TCP implementation). None of them, to the best of | my knowledge, declare any user-program-visible data types or constants. | Can you give us a list of the include files you need and what you need | them for? If there are some that are really useful to user applications, | we'll ship them. First off tcp(4p) explicitly mentions <netinet/tcp.h>. Secondly a fairly major piece of software, X V11, includes this file. I don't know about the rest of the files missing from <netinet>. My guess is that you should include the entire set and simply #ifndef apollo ... #endif the sections you don't feel you can support properly. Those sections will almost certainly be machine dependent and therefore not used by any application. This is also an assumption however, and may also get you into trouble. | | Several bugs really: | | | | 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 and allow their expansions to be concatenated | | properly. (Many older sources used the non-portable "/**/" | | equivalent.) Ex: | | | | #define foo(a, b) a##b | | | | The Apollo SR10 compiler totally barfs on this. Therefore I have to | | compile X.V11R3 with -A nansi. If the "##" construct is truly a part | | of Ansi C, can we get an update to Apollo's cpp that handles it | | properly? | | Yes, this is unfortunate but true. The problem is that the SR10 C | compiler is NOT a fully ANSI-compliant C compiler. In fact, the only | ANSI feature it really supports is function prototypes. This argues that | we shouldn't really be using __STDC__ as the flag to indicate presence of | function-prototype support in the compiler and include files. However, | it's too late to change this now; the fix will arrive when we finally | ship a true ANSI-compliant C compiler (no, I don't know when this is | scheduled for, sorry). If it's not an Ansi C compiler Apollo *definitely* should not be using __STDC__. I'm offended that Apollo has. I wish that ANSI had trademarked the symbol and forced anyone using it to validate their compiler. | | 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. I couldn't use | | __STDC__ for the above reason. So I have: | | | | #ifdef apollo | | #ifdef _BFMT__COFF | | #include <apollo/base.h> | | #include <apollo/time.h> | | #else | | #include "/sys/ins/base.ins.c" | | #include "/sys/ins/time.ins.c" | | #endif | | ... | | #endif | | | | In X.V11R3/lib/Xaw/Load.c. We really need something more along the | | lines of ``#ifdef SR10'' for this kind of thing however. | | | | 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. | | If people want, I will submit patches for these fixes. Can we get | | these installed in the standard Apollo release? | | You don't want to do that. The .h files in /usr/include/apollo must have | the function prototypes; that's how the compiler knows to pass the | arguments by reference as required by the underlying Pascal routines that | you're calling. We want these include files to generate compiler errors | when compiled without ANSI function prototype support, since otherwise | the generated code would have hard-to-diagnose run time errors resulting | from calling call-by-reference routines with arguments passed by value. But, but, but ... *sputter!* You tell me that Apollo doesn't really have an Ansi C compiler, therefore I'll have to compile a lot of stuff with the -A nansi (sic) flag, therefore anything that uses Apollo functionality, <apollo/*.h>, is doomed to failure ... I mean, do you want to offer a real solution or just tell me what I can't do? I've offered a completely reasonable solution to the problem (especially considering that the Apollo compiler turns out *not* to be anywhere close to being an Ansi C compiler) and all you can say is that it's not a good idea. What *is* a good idea???? Don't get me wrong, I like functional prototypes. I like type checking (with an escape mechanism). I like what the Ansi C committee has done in general. But since all Apollo implements is just functional prototyping, and since Apollo has chosen to use the Ansi C define __STDC__ to falsely claim that the compiler is an Ansi C compiler (and worse yet, this is the default), I have to compile with the -A nansi compiler flag. What is it? You want maybe I (and everyone else across the net) should put the following type of code into our programs? #ifdef __STDC__ # ifdef apollo ... # else ... # endif #else ... #endif The conversion to Ansi C was already going to be enough of a hassle, though well justified. Now Apollo in their infinite wisdom has decided to complicate the picture. (Many expletives deleted.) I just don't believe this ... At least if Apollo is going to screw things up, DON'T STAND IN THE WAY OF PEOPLE WHO ARE TRYING TO WORK THEIR WAY AROUND THE PROBLEMS THAT APOLLO HAS CREATED. Casey P.S. I don't in general include disclaimers because I take that as the standard. However, I feel that I should at least make it explicitly clear that these are my opinions, that all postings I have ever made, or ever will make, unless explcitly stated otherwise, are mine.
oj@apollo.COM (Ellis Oliver Jones) (11/04/88)
In article <17508@shemp.CS.UCLA.EDU> casey@CS.UCLA.EDU (Casey Leedom) writes: > 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. :-) >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. >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. >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 <apollo/gpr.h>. Some of them could get awful big if we had to go both ways. /Ollie Jones (speaking for myself, not necessarily for Apollo Computer, Inc.)
guy@auspex.UUCP (Guy Harris) (11/05/88)
>| It's very simple why we didn't ship all the "missing" header files in >| <netinet/>: they're all internal kernel include files that aren't used >| on Apollo (different TCP implementation). None of them, to the best of >| my knowledge, declare any user-program-visible data types or constants. > First off tcp(4p) explicitly mentions <netinet/tcp.h>. Secondly a >fairly major piece of software, X V11, includes this file. And, at least in the 4.3BSD implementation, there *ARE* user-program-visible contants in there, so it's perfectly legitimate for software like X11 to include it: /* * Copyright (c) 1982, 1986 Regents of the University of California. * All rights reserved. The Berkeley software License Agreement * specifies the terms and conditions for redistribution. * * @(#)tcp.h 7.1 (Berkeley) 6/5/86 */ ... /* * User-settable options (used with setsockopt). */ #define TCP_NODELAY 0x01 /* don't delay send to coalesce packets */ #define TCP_MAXSEG 0x02 /* set maximum segment size */
paul@DELRIO.CC.UMICH.EDU ('da Kingfish) (11/08/88)
It is an aggravation to have Apollo define __STDC__ and then not support everything one would expect, notably the ## thing. I modify /usr/include/sys/param.h to include a #define for the version of domain_os I have. Because I am a beta-tester, I get more releases than the average bear and need that to help keep things straight.
casey@admin.cognet.ucla.edu (Casey Leedom) (11/10/88)
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 <apollo/gpr.h>. 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 <paul@DELRIO.CC.UMICH.EDU> for his suggestion of adding an OS predefine (e.g.SR10_0). My fixes will probably include instructions for adding this to <apollo_$std.h>. Probably something along the line of: #define SR10_0 1 /* SR10.0 */ #define APOLLO_OS_SR 1000 /* ver.rel -> 100*ver + rel */ Casey