home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / aix / 8202 < prev    next >
Encoding:
Text File  |  1992-07-26  |  3.1 KB  |  71 lines
  1. Newsgroups: comp.unix.aix
  2. Path: sparky!uunet!newsgate.watson.ibm.com!yktnews!admin!yktnews!prener
  3. From: prener@watson.ibm.com (Dan Prener)
  4. Subject: Re: xlf -qextchk
  5. Sender: news@watson.ibm.com (NNTP News Poster)
  6. Message-ID: <PRENER.92Jul27025457@prener.watson.ibm.com>
  7. In-Reply-To: ron@sarah.lerc.nasa.gov's message of Mon, 27 Jul 1992 04:36:57 GMT
  8. Date: Mon, 27 Jul 1992 07:54:57 GMT
  9. Disclaimer: This posting represents the poster's views, not necessarily those of IBM
  10. References: <1992Jul27.043657.22336@eagle.lerc.nasa.gov>
  11. Nntp-Posting-Host: prener.watson.ibm.com
  12. Organization: IBM T.J. Watson Research Center, Hawthorne, New York
  13. Lines: 56
  14.  
  15. In article <1992Jul27.043657.22336@eagle.lerc.nasa.gov> ron@sarah.lerc.nasa.gov (Ron Gaug) writes:
  16.  
  17. >Does anyone know how to get some useful diagnostics from the xlf compiler's
  18. >extchk option? Here's an excerpt from the xlf manual page:
  19.  
  20. >            extchk      Perform procedure interface checking as well as
  21. >                        detection of mismatched common blocks.
  22.  
  23.   [lots of stuff deleted]
  24.  
  25. >        [hilbert]:514% xlf -v -qextchk -qsource extchk_bug.f
  26. >        exec: /usr/lpp/xlf/bin/xlfentry(xlfentry,extchk_bug.f,/tmp/F8FNsCkR,extchk_bug.lst,xlfsmsg.cat,xlfmsg.cat,EXTCHK,SOURCE,NULL)
  27. >        ** foo   === End of Compilation 1 ===
  28. >        ** xyzzy   === End of Compilation 2 ===
  29. >        1501-510  Compilation successful for file extchk_bug.f.
  30. >        0706-316 Error: Type mismatches detected. References dumped to load map.
  31.   [more stuff deleted]
  32.  
  33. >And the references to the type mismatches that were detected were dumped
  34. >to the load map.  Now if I could just get a load map. :-) And where's my a.out?
  35.  
  36. In order to get the loadmap, add the option
  37.  
  38.    -bloadmap:<filename>
  39.  
  40. and the loadmap will appear as the file you name in place of "<filename>".
  41. Well, actually it isn't a loadmap, but rather an inappropriately named
  42. log of linker actions and messages.
  43.  
  44. The reason you didn't get an a.out is that there was an error: your
  45. type mismatch.  Now, in case you are wondering about the remaining
  46. bunch of puzzling details, such as what were all those files being
  47. unlinked, and how would a log of linker actions and messages help if
  48. it never invoked ld, here is the crucial fact.  When xlf is given a
  49. file containing more than a single program or subprogram, it compiles
  50. them into multiple files, the strangely named files that were
  51. unlinked, in your posting, and then quietly feeds that collection of
  52. files to ld to do a partial link that will produce a single .o file.
  53. It was that hidden ld step that failed, causing the real ld, which
  54. would link in the libraries and produce an executable, never to be
  55. executed.  It was also the hidden ld whose "loadmap" would contain
  56. the messages you were looking for.
  57.  
  58. This explanation is given only to explain the details.  You should not
  59. have to concern yourself with the distinction between the hidden
  60. invocation of ld, and the usual one, e.g., when multiple files are
  61. compiled.  In both cases the messages will be found in the file you
  62. specify with the
  63.  
  64.     -bloadmap:<filename>
  65.  
  66. option.
  67.  
  68.  
  69. --
  70.                                    Dan Prener (prener@watson.ibm.com)
  71.