home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / sgi / graphics / 217 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.0 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!olivea!sgigate!odin!fido!owl!walker
  2. From: walker@owl.asd.sgi.com (Christopher Walker)
  3. Newsgroups: comp.sys.sgi.graphics
  4. Subject: Re: ImageVision and g++
  5. Message-ID: <1k49rfINNeo5@fido.asd.sgi.com>
  6. Date: 26 Jan 93 21:18:39 GMT
  7. References: <C1DHGr.B00@dcs.ed.ac.uk> <1k1b9mINN8a6@fido.asd.sgi.com> <C1Grqz.n4z@dcs.ed.ac.uk>
  8. Organization: Silicon Graphics, Inc.  Mountain View, CA
  9. Lines: 65
  10. NNTP-Posting-Host: owl.asd.sgi.com
  11.  
  12.  
  13. In article <C1Grqz.n4z@dcs.ed.ac.uk>, gordonc@epcc.ed.ac.uk writes:
  14. > In article <1k1b9mINN8a6@fido.asd.sgi.com>, walker@owl.asd.sgi.com (Christopher Walker) writes:
  15. > > 
  16. > > In article <C1DHGr.B00@dcs.ed.ac.uk>, gordonc@epcc.ed.ac.uk writes:
  17. > > > Sorry if this has been asked before, but can I use g++ (V2.0) to compile
  18. > > > ImageVision C++ progs, and if so, which options should I use ??
  19. > > > 
  20. > > > Any help appreciated,
  21. > > 
  22. > > We've never tried.. but I strongly doubt that SGI's C++ and gnu's C++ are
  23. > > compatible.  Maybe someone with more experience with g++ would know.  I suspect
  24. > > that the IL would need to be recompiled with g++ and there isn't much likelihood
  25. > > of SGI supporting that.. sorry.
  26. > > 
  27. > 
  28. > .....ermmm, isn't the language specification for C++ fairly strict? If I were to take pieces of C code from my SGI and attempt to compile them elsewhere, I'd like to think that I wouldn't experience too much trouble :-) (also,for example, I can compile GL programs with gcc)
  29. > 
  30.  
  31. IL ports just fine to the other platforms we've tried.  That's not the issue.
  32. The problem is in how the compilers implement various tricks..
  33.  
  34. > Incidentally, the trouble is in the linking stage. With the options, -traditional-cpp and -x c++, all is OK until link, when I get :
  35. > 
  36. > gcc -x c++ -traditional-cpp -o imgcat imgcat.c++
  37. > 
  38.  
  39. Like name mangling.. the names below show me that g++ mangles differently than
  40. ATT's cfront.  I'm sure there are deeper problems like the layout of vtbl's and
  41. other such goodies.. in short I'd give up while your ahead :-)
  42.  
  43. C++ just isn't as interoperable as you might like because of these little 
  44. hacks that have been used to fool the linker (which knows nothing about 
  45. overloading and class names etc.)
  46.  
  47. > Undefined:
  48. > getElem__C7ilPixeli
  49. > findLink__15ilIndexableListl
  50. > _._15ilIndexableList
  51. > inList__9ilImgListP7ilImage
  52. > findImg__9ilImgListP7ilImage
  53. > firstImg__9ilImgList
  54. > lastImg__9ilImgList
  55. > nextImg__9ilImgList
  56. > resetCheck__7ilImage
  57. > __as__7ilPixelRC7ilPixel
  58. > ilDataIsSigned
  59. > setInput__7ilImagePT0i
  60. > findParent__7ilImagel
  61. > findChild__7ilImagel
  62. > _._10ilCacheImg
  63. > ilOpenImgFile
  64. > ilCreateImgFile
  65. > childResponse__7ilImagePT0
  66. > parentResponse__7ilImagePT0
  67. > reset__10ilCacheImg
  68. > getSubTile3D__10ilCacheImgiiiiiiPviiiiiiPC8ilConfig
  69. > setSubTile3D__10ilCacheImgiiiiiiPviiiiiiPC8ilConfig
  70. > copyTile3D__10ilCacheImgiiiiiiP7ilImageiiiPii
  71. > fillTile3D__10ilCacheImgiiiiiiPvPC8ilConfigPC6ilTile
  72. > flush__10ilCacheImg
  73. > collect: /usr/bin/ld returned 1 exit status
  74. > 
  75. ---
  76. Chris Walker (x1106 or walker@sgi.com)
  77.