arritt@kuhub.cc.ukans.edu (09/18/90)
Has anyone been having problems compiling Fortran code under 3.3? I just
installed 3.3 and tried to compile one of the models I've been using, and
got the following error message:
f77 -static -Olimit 1400 -O1 -c hill2dc.f
ugen: internal: error in write, writing 6528 bytes instead of 8192 bytes
*** Error code 1
Stop.
What does this mean? I've never seen anything like it before.
The code worked fine under 3.2 and is totally unmodified since before the
3.3 installation (I can show an ls -lrt to prove it ...) Several
other pieces of code of comparable length and complexity compile properly
under 3.3, so it's apparently not that the code is too big. I might add
that the error occurs with both -O1 and -O2 for whatever it's worth
(haven't tried with no optimization; that isn't viable because the jobs
take 20-30 cpu hours even under -O2).
Thanks for whatever help you can provide. (I've had no luck with the
so-called "hotline".)
________________________________________________________________________
Raymond W. Arritt |
Assistant Professor |
Dept. of Physics and Astronomy | "everyone knew that as time went
Univ. of Kansas | by we'd get a little bit older
Lawrence, KS 66045 | and a little bit slower..."
arritt@kuhub.cc.ukans.edu |
arritt@ukanvax.bitnet |
drb@eecg.toronto.edu (David R. Blythe) (09/22/90)
In article <25656.26f4d43b@kuhub.cc.ukans.edu> arritt@kuhub.cc.ukans.edu writes: >Has anyone been having problems compiling Fortran code under 3.3? I just >installed 3.3 and tried to compile one of the models I've been using, and >got the following error message: > > > f77 -static -Olimit 1400 -O1 -c hill2dc.f > >ugen: internal: error in write, writing 6528 bytes instead of 8192 bytes >*** Error code 1 > >Stop. > > I have had this happen to me with large fortran source files under 3.2. I find using fsplit to break up the fortran source into one subroutine per file, gets around the problem but its not a solution I am happy with. drb :-(
phil@AKIKO.PRINCETON.EDU ("Philip D. Jeffrey") (09/22/90)
In article <25656.26f4d43b@kuhub.cc.ukans.edu> arritt@kuhub.cc.ukans.edu writes: Status: R >Has anyone been having problems compiling Fortran code under 3.3? I just >installed 3.3 and tried to compile one of the models I've been using, and >got the following error message: > > > f77 -static -Olimit 1400 -O1 -c hill2dc.f > >ugen: internal: error in write, writing 6528 bytes instead of 8192 bytes >*** Error code 1 > >Stop. > > It happened to us when compiling a graphics program that compiled fine under 3.2 (4D/25TG) and didn't under 3.3 (4D/340VGX). It turned out that /tmp was filling up with temporary files written by ugen, if I recall correctly. We expanded /tmp using a link to /usr/tmp (the perils of doing this sort of thing have been previously discussed on this network), and now the programs compile just fine. Phil Jeffrey Bristol-Myers Squibb Pharmaceutical Research Institute phil@akiko.princeton.edu
davea@quasar.wpd.sgi.com (David B.Anderson) (09/25/90)
In article <9009220353.AA08099@akiko.Princeton.EDU>, phil@AKIKO.PRINCETON.EDU ("Philip D. Jeffrey") writes: > In article <25656.26f4d43b@kuhub.cc.ukans.edu> arritt@kuhub.cc.ukans.edu writes: > Status: R > > >Has anyone been having problems compiling Fortran code under 3.3? I just > >installed 3.3 and tried to compile one of the models I've been using, and > >got the following error message: > > > > > > f77 -static -Olimit 1400 -O1 -c hill2dc.f > > > >ugen: internal: error in write, writing 6528 bytes instead of 8192 bytes > >*** Error code 1 > > > >Stop. > > > > > > It happened to us when compiling a graphics program that compiled fine under > 3.2 (4D/25TG) and didn't under 3.3 (4D/340VGX). It turned out that /tmp was > filling up with temporary files written by ugen, if I recall correctly. We > expanded /tmp using a link to /usr/tmp (the perils of doing this sort of thing > have been previously discussed on this network), and now the programs compile > just fine. A simpler and safer solution to running out of space during compiles is setenv TMPDIR /usr/tmp (using csh terminology) for example or TMPDIR=/usr/tmp ; export TMPDIR (using sh/ksh) See the f77(1) or cc(1) man page. Regards, [ David B. Anderson Silicon Graphics (415)335-1548 davea@sgi.com ] [``What can go wrong?'' --Calvin and Hobbes]
blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") (09/25/90)
But setting TMPDIR to /usr/tmp only gets part of the problem. If
you try to edit a file that is too big you will fill root. There are
two real solutions: 1) use a symbolic link between /tmp and /usr/tmp
(this seams to be the best solution); 2) repartion the disk to make
root bigger.
Actually, doing both is a good idea with 3.3. We installed 3.3.1
last week (actually our SGI systems engineer did) and the installation
stopped part way through because there wasn't enough disk space in root.
--
Brent L. Bates
NASA-Langley Research Center
M.S. 361
Hampton, Virginia 23665-5225
(804) 864-2854
E-mail: blbates@aero4.larc.nasa.gov or blbates@aero2.larc.nasa.govjwag@moose.asd.sgi.com (Chris Wagner) (09/25/90)
In article <9009251048.AA17257@aero4.larc.nasa.gov>, blbates@AERO4.LARC.NASA.GOV ("Brent L. Bates AAD/TAB MS361 x42854") writes: > > But setting TMPDIR to /usr/tmp only gets part of the problem. If > you try to edit a file that is too big you will fill root. There are > two real solutions: 1) use a symbolic link between /tmp and /usr/tmp > (this seams to be the best solution); 2) repartion the disk to make > root bigger. > Actually, doing both is a good idea with 3.3. We installed 3.3.1 > last week (actually our SGI systems engineer did) and the installation > stopped part way through because there wasn't enough disk space in root. In vi the 'set directory' option lets you point the temp file anywhere Chris Wagner