home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / fortran / 2820 < prev    next >
Encoding:
Text File  |  1992-07-24  |  1.3 KB  |  27 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!utcsri!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system
  3. From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
  4. Subject: Re: why are fortran binaries so large?
  5. Message-ID: <1992Jul24.170926.214@alchemy.chem.utoronto.ca>
  6. Organization: University of Toronto Chemistry Department
  7. References: <dedmunds.711917278@sfu.ca> <OHL.92Jul23231746@ips105.desy.de>
  8. Date: Fri, 24 Jul 1992 17:09:26 GMT
  9. Lines: 16
  10.  
  11. In article <OHL.92Jul23231746@ips105.desy.de> ohl@ips105.desy.de (Thorsten Ohl) writes:
  12. >
  13. >At least on Apollos and HP-UX boxes you can trick the compiler to
  14. >allocate the offending array in the BSS segment by putting it into a
  15. >COMMON block.  Yes, it's a hack, but it can reduce the size of your
  16. >binaries tremendously.
  17.  
  18. If you use the '-K' option (to save and zero your variables), HP-UX
  19. will always create a huge executable; Apollo/Domain, SGI and IBM
  20. RS/6000 do not even when SAVE (or the compiler switch equivalent) is
  21. used, unless of course DATA is used to actually initialize
  22. the variables/arrays, when there is no alternative except to write
  23. them into the executable. Otherwise the COMMON trick does the job.
  24. -- 
  25. What are the chances that any computer system will ever "work" properly?
  26. ... and Slim just left town. -*- Mike Peterson, SysAdmin, U/Toronto Chemistry
  27.