home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / informix / 1761 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  3.0 KB

  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!europa.asd.contel.com!emory!salmon.demon.co.uk
  2. From: neil@salmon.demon.co.uk ("Neil S. Briscoe")
  3. Newsgroups: comp.databases.informix
  4. Subject: Redeclaration of local variables (?)
  5. Message-ID: <9371@emory.mathcs.emory.edu>
  6. Date: 21 Aug 92 12:08:05 GMT
  7. Sender: walt@mathcs.emory.edu
  8. Reply-To: neil@salmon.demon.co.uk ("Neil S. Briscoe")
  9. Lines: 63
  10. X-Informix-List-ID: <list.1387>
  11.  
  12. Jonathon,
  13.  
  14. You wrote:
  15.  
  16. >>I had the message:
  17. >>ut_merge.c Line 4351 redeclaration of prepare_sel_
  18. >
  19. >This is therefore probably a C compiler error message.  If it came
  20. >from 4GL, the file referenced would be ut_merge.4gl; if it came from
  21. >ESQL, the file referenced would be ut_merge.ec.  Also, the message
  22. >format is more like that used by the C compiler...
  23.  
  24. Sorry.  Well of course you're right and I new the message was not from
  25. c4gl itself by then, I merely mentioned this so that folks would know
  26. I was working from make and not from the programmers environment.
  27.  
  28. >In fact, I would expect an error message to refer to the .ec file even
  29. >if the compiler was compiling the C produced from the .ec file...
  30.  
  31. I would expect that.  But both this version and 4.10.... on the Sparc
  32. always state blah.c.  Only lowly 1.10.00B states blah.ec.
  33.  
  34. >When you checked the source, did you look at the I4GL code or the generated
  35. >C code?  I would expect your observation to be valid for both, which would
  36. >then indicate a broken C compiler -- however, you don't get many broken
  37. >C compilers on Unix boxes, so it needs more careful scrutiny.
  38.  
  39. I must admit that so far I've only checked the 4GL.  I fixed this
  40. particular variable by making it global.  The reason I did this was
  41. because it, amongst other variables, were listed in ld's list of
  42. undefined symbols.  I've grepped for all of these variables in the 4gl
  43. code and the objects are in the library.
  44.  
  45. >Have you tracked down the declarations of prepare_sel_ in the C code?
  46. >Are these internal to the function or external to them?  If internal and
  47. >the compiler is wittering, then you have a seriously defective compiler.
  48. >If external, then we have a question of what is being done on your other
  49. >machines where it does work.  Where are the variables declared on those
  50. >other machines?
  51.  
  52. Thanks for the hint.  As you might guess, I don't often program in C.
  53.  
  54. >None of this is a definitive answer, but to give one would need much more
  55. >information than should be sent over the net...
  56.  
  57. Accepted.  Again, thanks very much.
  58.  
  59. Regards
  60. Neil
  61.  
  62.  
  63. Neil S. Briscoe                Telephone: +44 252 376737
  64. System Administrator            Fax:       +44 252 376644
  65.                                         Email: neil@salmon.demon.co.uk
  66.                                                nbriscoe@cix.compulink.co.uk
  67. Bartec Medical Systems Ltd.
  68. Impression House
  69. Invincible Road                "!##@!** Listen who swears
  70. Farnborough                 Christopher Robin has fallen downstairs"
  71. Hants GU14 7NP                -- The Goodies Book of Criminal Records
  72. England
  73. "A man is incomplete until he's married -- then he's finished!"
  74. -- seen on a desktop calendar
  75.