jon@oddhack.UUCP (04/18/87)
In article <387@sdd.UUCP> dc@sdd.UUCP (Root) writes: >In article <2348@cit-vax.Caltech.Edu> jon@oddhack.Caltech.EDU (Jon Leech) writes: >> Assuming this is the same problem I had with 1.1, you will find >>that <CC/signal.h> #include's <sys/signal.h>. No <CC/sys/signal.h> was >>supplied, however, and thus the system-supplied /usr/include/sys/signal.h >>gets included. It contains a declaration of signal() which conflicts with >>that in the C++ supplied <CC/signal.h>. What you need to do is: >> $ cp /usr/include/sys/signal.h /usr/include/CC/sys/signal.h >>and make the signal declaration therein agree with <CC/signal.h> > > Do NOT copy /usr/include/CC/signal.h to /usr/include/CC/sys/signal.h. >This is because C++'s signal.h includes sys/signal.h! This would cause >recursive includes. This include of sys/signal.h provides the local >system defines for the various signals and therefore should work on >BSD. Daniel, do me the favor of READING my posting! I did NOT say any such thing. See the nice line with the $ prompt above? Read it carefully. Here, I'll just copy it again to make sure you get the point: >> $ cp /usr/include/sys/signal.h /usr/include/CC/sys/signal.h >>and make the signal declaration therein agree with <CC/signal.h> Sorry to be abrupt but I get annoyed when people misquote my postings like this. I have done what I recommended above. It IS what you want to do. It works perfectly. In point of fact, you want ALL your system .h files containing function declarations to be copied into the /usr/include/CC tree and modified to contain prototypes, but this is not frequently needed; getting <stdio.h> and <sys/signal.h> is about all you usually need. If you don't want to create two copies of these files to look after, use the preprocessor symbol 'c_plusplus' to separate C and C++ declarations. The include files supplied with C++ get most of what you will use - but most is not all. Bjarne can't very well include many of the files in the sys/ directory, for obvious reasons. Systems programmers using C++ are going to be forced to modify these system-specific include files appropriately. Non-System V ports and vendor-supplied additional libraries & include files also can create problems. An example is the Sun graphics library header files, which use an extension to C involving unsigned casts in constant expression, not recognized by C++. I've ended up using high-level C 'hooks' to such libraries rather than going to the horrible pain of editing dozens of include files. It sure would be nice if C++ became an official part of System V... many of these porting problems might go away. Any word of this happening, netlanders? -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon) Caltech Computer Science Graphics Group __@/