#135 flexraw fails on Intel OS X with gfortran

critical
closed-works-for-me
core (120)
6
2008-06-16
2006-04-06
Karl Glazebrook
No

Built PDL v2.4.2 on OS X 10.4.5 Intel with gcc v4.0.1 and gfortran 4.2.0
(which is apparently the new replacement for g77()

Test t/flexraw.t fails:

[PDL-2.4.2] % perl -Mblib t/flexraw.t
1..29
# Running under perl version 5.008006 for darwin
# Current time local: Thu Apr 6 05:32:12 2006
# Current time GMT: Thu Apr 6 09:32:12 2006
# Using Test.pm version 1.25

ExtUtils::F77: Version 1.16
Loaded ExtUtils::F77 version 1.16
Found compiler gfortran
ExtUtils::F77: Using system=Darwin compiler=GFortran
Checking for gcc in disguise:
Compiler is gcc version 4.0.1 (Apple Computer, Inc. build 5250)
Runtime: -L/usr/local/lib -lgfortran -L/usr/lib/gcc/i686-apple-
darwin8/4.0.1 -lgcc
ExtUtils::F77: Validating -L/usr/local/lib -lgfortran -L/usr/lib/gcc/
i686-apple-darwin8/4.0.1 -lgcc [ok]
ExtUtils::F77: Compiler: gfortran
ExtUtils::F77: Cflags:
Error: Doesn't look like f77 file (even swapped) at /Users/kgb/
Downloads/PDL-2.4.2/blib/lib/PDL/IO/FlexRaw.pm line 468

It appears that the first test, writes a data file with this fortran program

c Program to test i/o of F77 unformatted files
program rawtest
implicit none
integer i
real*4 a(10)
do i = 1, 10
a(i) = 100.*sin(0.01* i)
enddo

open(8,file='/tmp/tmprawdata'
$,status='new',form='unformatted')
i = 10
write (8) i
write (8) a
close(8)
end

This is the header:

[PDL-2.4.2] % cat /tmp/tmprawdata.hdr
# FlexRaw file header
f77
long 1 1
# Data
float 1 10

I guess the new gfortran is doing something wierd with it's
unformatted IO?

No idea who to assign this too! The PDL::IO::FlexRaw module has been
stable for a number of years! Author is Robin Williams in 1997!!! Zowie
made the last change 2 years ago.

The raw files are attached in a archive

Note running the fortran program with g77 on a older PPC Mac DOES
produce a file readflex can read. - So this is maybe a gfortran bug not
a PDL one?

Discussion

  •  
    Attachments
  • Tim Jenness
    Tim Jenness
    2006-04-06

    Logged In: YES
    user_id=23633

    Probably a gfortran bug since gfortran is (was?) very very buggy. Please try it
    with g95 (www.g95.org) instead (g95 is compatible with gcc4 and works on intel
    osx - there is a fink build)

     
  • David Hull
    David Hull
    2006-05-31

    Logged In: YES
    user_id=263476

    I saw this failure too with gfortran on Fedora Core 5 x86.

    It looks like gfortran uses a different padding. Here is a
    hex dump of output of a gfortran:

    0000000 0004 0000 0000 0000 000a 0000 0004 0000
    0000010 0000 0000 0028 0000 0000 0000 0000 3f80
    0000020 0000 4000 0000 4040 0000 4080 0000 40a0
    0000030 0000 40c0 0000 40e0 0000 4100 0000 4110
    0000040 0000 4120 0028 0000 0000 0000
    000004c

    And here is the output of the same program compiled with f77:

    0000000 0004 0000 000a 0000 0004 0000 0028 0000
    0000010 0000 3f80 0000 4000 0000 4040 0000 4080
    0000020 0000 40a0 0000 40c0 0000 40e0 0000 4100
    0000030 0000 4110 0000 4120 0028 0000
    000003c

    The difference is that the gfortran version appears to have
    some extra padding.

    Here is the program:

    c Program to test i/o of F77 unformatted files
    program rawtest
    implicit none
    integer i
    real*4 a(10)
    do i = 1, 10
    a(i) = i
    enddo

    open(8,file='xx'
    $,status='new',form='unformatted')
    i = 10
    write (8) i
    write (8) a
    close(8)
    end

     
  • Logged In: YES
    user_id=1796

    So does anyone here know enough about PDL::IO::FlexRaw to fix the padding in
    the gfortran case?

    Or should we regard this as a gfortran bug?

     
  • Chris Marshall
    Chris Marshall
    2007-02-28

    Logged In: YES
    user_id=44920
    Originator: NO

    From the gfortran wiki(http://gcc.gnu.org/wiki/GFortran):

    ...
    GFortran 4.2 and 4.3 use now 4-byte record markers by default for unformatted files to be compatible with g77 and most other compilers. The implementation allows for records bigger than 2 GB, compatible with several other compilers. Older versions of GFortran used by default 8-byte record markers (on most systems); in order to change length of record markers, e.g. to the read unformatted files created by older gfortran versions, the -frecord-marker=8 option can be used.
    ...

    So it appears that this was a gfortran compatibility issue
    that has now been resolved. Perhaps someone with gfortran
    using the f77 compatible 4byte record markers could verify
    and close this bug.

     
  • Craig DeForest
    Craig DeForest
    2008-06-16

    • status: open --> closed-works-for-me
     
  • Craig DeForest
    Craig DeForest
    2008-06-16

    Logged In: YES
    user_id=20200
    Originator: NO

    This problem has gone away with the latest MacOS X and gfortran.