home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / cplus / 16239 < prev    next >
Encoding:
Text File  |  1992-11-14  |  2.4 KB  |  60 lines
  1. Xref: sparky comp.lang.c++:16239 comp.sys.hp:12894
  2. Newsgroups: comp.lang.c++,comp.sys.hp
  3. Path: sparky!uunet!pilchuck!fnx!sgihbtn!dkarr
  4. From: dkarr@sierra.com (David Karr)
  5. Subject: C code from cfront doesn't compile
  6. Message-ID: <1992Nov11.231655.21277@sierra.com>
  7. Sender: news@sierra.com
  8. Nntp-Posting-Host: dopey
  9. Organization: Sierra Geophysics,  Kirkland WA
  10. X-Newsreader: Tin 1.1 PL4
  11. Date: Wed, 11 Nov 1992 23:16:55 GMT
  12. Lines: 46
  13.  
  14. We have been running into a bug with the HP C++ compiler that occurs when
  15. we try to compile certain source files with "-g" to keep a symbol table.
  16. The compiler fails with an "internal error".  This subject has been written
  17. about previously in this newsgroup.
  18.  
  19. I've been trying to find a workaround for this.  I may have found one, but
  20. it is quite painful, and the reason it is painful is because of a bug in
  21. either the HP C++ compiler or the HP C compiler, I'm not sure which.
  22.  
  23. The normal operation of the C++ compiler is to generate object code
  24. directly from the C++ source.  There is an option called "translator mode"
  25. (the "+T" option) which makes the C++ compiler generate C code, and then
  26. pass that code to the C compiler.  I thought I would experiment with that
  27. by looking at the generated C code and see if there was something screwy
  28. about it, and then try to manually compile that with the C compiler.  I
  29. found that the original C code generated by cfront would not compile with
  30. the C compiler.  I found it generating sequences of code like this:
  31.  
  32. -------------------
  33. struct something;
  34. struct something { int stuff; }
  35. struct something;
  36. -------------------
  37.  
  38. The C compiler would flag the last "forward" declaration with an error
  39. saying:
  40.  
  41.     error 1587: Redeclaration of tag "something"
  42.  
  43. I hand-edited the generated C source, removing all the "post-forward"
  44. references, then I recompiled (with "-g").  It compiled with no errors.  I
  45. haven't tried linking the final object file with the rest of my C++ objects
  46. to see whether it would make any sense.
  47.  
  48. I don't know whether the "error" is on the part of the C++ compiler or the
  49. C compiler, it just doesn't work.
  50.  
  51. The question is, is anyone aware of this situation?  Will the "manually"
  52. generated object file link properly with a collection of C++ objects, and
  53. will I be able to debug this executable in a debugger and look at the
  54. symbols from the original source file?
  55. --
  56. David M. Karr
  57. Sierra Geophysics, Inc.
  58. ARPA: dkarr@sierra.com, UUNET: uunet!sgihbtn!dkarr
  59. Phone: (206) 822-5200 (x343)
  60.