crm@romeo.cs.duke.edu (Charlie Martin) (02/26/90)
Can anyone point me to the appropriate place for ANSI-conformant .h files for Suns, or tell me the canonical way in which to use gcc on Suns with the existing header files? Please reaply by mail, as I don't normally read this group. Thanks, Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)
rfg@ics.uci.edu (Ronald Guilmette) (02/28/90)
In article <17794@duke.cs.duke.edu> crm@romeo.cs.duke.edu (Charlie Martin) writes: >Can anyone point me to the appropriate place for ANSI-conformant .h >files for Suns, or tell me the canonical way in which to use gcc on >Suns with the existing header files? (Advice on generating "better" include files for various systems is given below. But first you must suffer through my tirade! :-) The whole situation with regard to "system" include files seems a bit muddled at the moment. Whenever the GNU C library becomes available, it is my understanding that it will come with a set of include files of its own. I can only hope that these will be tested with g++ (and with cfront) and that they will be compatible with those. (I'm willing to help test for compatability when the time comes.) Also, one must assume that when there is a GNU kernel, that *it* will also come with its own include files. Again, I hope that these will be provided in a form that is compatible with gcc, g++ and cfront. For both of the above groups of GNU include files, the question which looms large is: Will these include files contain function prototypes? If so, then they may be compatible with C++ language processors, but they may break non-GNU C compilers. If not, then using any sort of C++ language processor with other GNU stuff (i.e. kernel & C library) will be quite impossible. Either way, *some* combination of stuff will not work. Another complication is the set of include files now provided with libg++. Will these be merged (somehow) with the other two sets of GNU include files mentioned above? I (for one) don't know the answer to that question (but I would very much like to). Yet more complications arise during this interm period while we are all waiting for the GNU C library and the GNU kernel to arrive. (And for those people who will not be able to go pure-GNU for political reasons, these problems will persist even after the GNU kernel and C library arrive). In particular, the question arises: How can I use my brand X computer (with my brand X kernel and C library) right now and still be able to use gcc and g++? Well, for gcc, there is a special script called "fixincludes" that tries to help you workaround certain known instances of non-standard (or just plain wrong) usage in *some* include files for *some* popular systems (most notably Sun). Unfortunately, fixincludes is only a stopgap solution (and not a very robust one). It certainly doesn't claim to fix *all* the problems in *all* the system include files for *all* of the hardware and *all* of the operating system revision levels that GCC now runs on. To get it to handle *all* of these cases would take several man years. Even if it did handle all these cases flawlessly, fixincludes makes no attempt to introduce function prototypes (needed for C++ compatability and generally useful anyway) into the "fixed" system include files. It is thus a rather minor tool, lacking some of the more important aspects of functionality that such a tool would (in an ideal universe) have. For g++, there is a whole slew of out-and-out *replacement* system include files which completely override many (but not all) system include files for many (but not all) popular machines. Keeping these compatible with zillions of different possible g++ host/target systems is (I'm sure) keeping Doug Lea very busy. As g++ (and libg++) gain popularity, I keep expecting to read on net news that D.L. has been found dead of exhaustion at his worstation while making one last compatability hack to the libg++ include files. :-) As with fixincludes, there is no way that Doug can possibly keep up with *all* of the machines and OS revision levels that gcc, g++, and libg++ are being ported to. I am not even going to dwell on the *additional* compilcations that arise for people who want to use both g++ and AT&T's cfront on the same system, other than to note that cfront also comes with *its* own (different) set of semi-replacement include files. So what is a poor user to do? Well, if we get a GNU kernel and a GNU C library (and if we can all convince our local managements to use them) then we will probably be home free (if we can assume that the relevant include files will be "fixed" and prototyped and compatible with both ANSI C and C++). Until then, you can use fixincludes to solve part of the problem (i.e. the out-and-out non-ANSI'isms) on *some* systems. Solving the prototypes problem is a bit harder but still doable. If I get time, I plan to create a heavily modified version of fixincludes which can invoke my protoize program to automatically add *all* needed function prototypes to known sets of "native" system include files for various popular systems. You can do this yourself right now by making clever use of "source" lint libraries. I can provide more details to interested parties via E-mail. Once my "protoizing fixincludes" exists, I assume that the gcc-include directory will tend to fill up quite a bit more than it now does with replacement (i.e. "fixed") include files. Probably, you will end up with fixed (and protoized) versions of almost all of your native include files. This will be a great boon for C++ programmers who are currently unable to make use of tons of system-specific features (like for instance neat parallel stuff on Sequents) simply because the native system include files don't have the prototypes needed to be compatible with C++. Anyway, I'm concerned about the include file issue because it seems to be an area where everybody is off doing their own thing (especially the computer system manufacturers, most of whom don't even bother to get ANSI-C compatible). There appears to be neither concensus nor coordination. I can only hope that people will begin to realize the truth of that old maxim: "No include files is an island." // Ron Guilmette (rfg@ics.uci.edu) // C++ Entomologist // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
djm@eng.umd.edu (David J. MacKenzie) (02/28/90)
In article <25EAFC22.967@paris.ics.uci.edu> rfg@ics.uci.edu (Ronald Guilmette) writes: > Whenever the GNU C library becomes available, it is my understanding that > it will come with a set of include files of its own. I can only hope that > these will be tested with g++ (and with cfront) and that they will be > compatible with those. (I'm willing to help test for compatability when > the time comes.) I've seen the development sources to the GNU C library. It is ANSI (and POSIX) conformant, but uses some clever ifdefs to generate prototypes on __STDC__ and declarations on traditional C compilers. I haven't tried using it with C++. Roland McGrath is taking great pains to make it portable, though. > Also, one must assume that when there is a GNU kernel, that *it* will > also come with its own include files. Again, I hope that these will be > provided in a form that is compatible with gcc, g++ and cfront. The GNU kernel will probably be based on Mach, for whatever that's worth. -- David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu>
andrew@alice.UUCP (Andrew Hume) (02/28/90)
gosh, sounds like doug lea is being worked to death. headers are a real pain, particularly if you need to be compatible with extant systems. perhaps the person in charge of gratuitous extensions to gcc (e.g. nested functions) could do something useful and help doug?