Path: utzoo!attcan!uunet!spool.mu.edu!sdd.hp.com!apollo!apollo.hp.com!zaino
From: zaino@apollo.HP.COM (Bart M. Zaino)
Newsgroups: comp.sys.apollo
Subject: Re: Problems with Fortran-Compiler
Message-ID: <501a8063.20b6d@apollo.HP.COM>
Date: 1 Mar 91 12:51:00 GMT
References: <250@mailgzrz.tu-berlin.de>
Sender: root@apollo.HP.COM
Reply-To: zaino@apollo.HP.COM (Bart M. Zaino)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 67


>>Two weeks ago, we upgraded our DN10000 to SR10.3.
 >>During the installation-process, we had to re-install our
 >>fortran- and c-compilers. Since this day we have got a
 >>disk-space consuming problem with our fortran-software.
 >>
 >>We are doing FEM-calculations which require the use of large
 >>arrays. The arrays are of static size and declared in the
 >>program header. The compiler is running well and .o-Files of 
 >>normal size are generated. When the program is linked, it seems 
 >>that all the arrays are allocated, filled with nothing 
 >>and then are written into the executable file, so that a large 
 >>amount of diskspace is wasted. Under SR10.2p the executables 
 >>where of normal size (which means some 100k), now they take MEGABYTES.  
 >>
 >>We are using the Fortan-Compiler v10.7p. Since we haven't got
 >>much UNIX experience yet, there is a good chance we made some
 >>installation mistake.
 >>
 >>Does anybody know, how this problem can be solved?    
                           
                 
A problem was discoveed in sr10.3 fortran problem and may be fixed
with the following patch. available from your local HP response center:

pd91_p0201 9101    /lib/ftnlib   

   1. compatible environments:  sr10.3.p
   2. fixes various problems
     - I/O intensive programs were not returning disk space
    - correct reading after rewind
    - ftn was failing to perform I/O on named pipes
  3. Library time stamp  1990/12/03 10:07:01 EST (Mon)  

You may also want to investigate the following option to the binder
to reduce the size of your executable.

A new option to /com/bind, -sparse_vm, enables the SR9.7 dynamic disk
allocation behavior for programs run on SR10.2 or later. Currently, the
new behavior affects only the break area, which includes the .bss area
and that used by malloc(). It does not affect memory allocation for
rws_$ calls.

You will find the -sparse_vm option particularly useful if all of the
following are true:

     o Your program is in FORTRAN
     o Your program contains very large arrays
     o You have a small amount of free disk space

Limitations: 

   o The -sparse_vm option must not be used with C programs that make
     the fork() system call, because child processes will not have their 
     own distinct break area.

   o This option is not available through the Unix linker, /bin/ld at versions
     below sr10.3. 
     Programs bound with ld should be written with dynamic allocation 
    built into the code by the programmer, via malloc() calls for example.

    
Regards,

Bart M. Zaino
HP/Apollo
Chelmsford Response Center