SCIENTIFIC-LINUX-USERS Archives

September 2007

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
John Summerfield <[log in to unmask]>
Reply To:
John Summerfield <[log in to unmask]>
Date:
Wed, 19 Sep 2007 14:15:05 +0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (63 lines)
Hendrik van Hees wrote:
> Dear SL Users,
> 
> I have a (perhaps stupid) question. Some time ago I switched to SL 5.0 
> (from various SuSE distributions).
> 
> Now I've run into a problem with the compatibility of g77. On our 
> workstations we have SuSE (guess who's the sys admin ;-)) with
> 
> gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)

That's not SLE{D,S} 10. SLED 10 has gcc 4.1.

> 
> On my laptop and on other machines in our institute, I have SL with
> 
> gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)

That's sl4. SL5 has cpp (GCC) 4.1.1 20070105 (Red Hat 4.1.1-52)



> 
> In 99.9% of all cases there is no problem with my (rather simple) codes. 
> I can compile them without trouble. Only when I do some (either very 
> simple) I/O, an incompatibility occurs. It happens if I write to a file 
> and then read in the same file again within the same program. This 
> worked without trouble in the older gcc version, but creates weird 
> run-time errors in the new version:
> 
> invalid number: incomprehensible list input
> apparent state: unit 1 named RW-total-tadmix4pi-6pi-om-phi-DY.dat
> last format: list io
> lately reading sequential formatted external IO
> Aborted
> 
> Here, "RW-total-tadmix4pi-6pi-om-phi-DY.dat" is the file I write to disk 
> and then read it in again.
> 
> Of course it's not a big deal to rewrite the code that this is 
> re-reading not necessary. But, if someone knows a compiler switch or 
> the like so that the writing out and reading in of a file in the same 
> program works again, it would save me some time.

Without the relevant source code and other materials necessary to 
recreate the problem, I don't see that anyone can provide much help. 
_My_ first suspicion would be the program.

Next, I would wonder whether the later compiler implements a later 
standard, or whether it's fixed some problem.



-- 

Cheers
John

-- spambait
[log in to unmask]  [log in to unmask]

Please do not reply off-list

ATOM RSS1 RSS2