From: craigberry@nospam.mac.com   
      
   On 9/8/25 9:05 PM, Waldek Hebisch wrote:   
   > Craig A. Berry  wrote:   
   >> On 9/7/25 1:17 PM, Waldek Hebisch wrote:   
      
   >>> Yes, I st_ino on VMS is an array.  I have now modified libgfortran   
   >>> to accomodate this.   
   >>   
   >> Yes and no.  If you insist on using decades-old VAX C compatibility   
   >> features, then st_ino is an array.  Probably because you couldn't fit 3   
   >> words into any integral type on VAX.   
   >>   
   >> If you define _USE_STD_STAT, though, then you get:   
   >>   
   >> typedef unsigned __int64    __ino_t;   
   >> typedef __ino_t ino_t;   
   >>   
   >> You also get large file support, which you could get independently via   
   >> _LARGEFILE if for some reason you had to.  You definitely want   
   >> _USE_STD_STAT for anything new and/or cross-platform.  That gets you   
   >> something that was POSIX-compliant a decade or two ago. It isn't   
   >> compliant now because the file times are still just ints rather than   
   >> structs with high-precision components as newer POSIX requires.   
   >   
   > Well, the contex is libgfortran, part of Fortran compiler.  It is   
   > supposed to work with 60 years old Fortran code.  Such code may need   
   > compatiblity features.   
      
   I'm not sure I follow; that sounds like a conflation of compiler build   
   time and compiler run time (user source build time) requirements.   
      
   > ATM I did not look if/how gcc supports such switches.  This is   
   > certainly thing to look at later, but now I want old stuff to   
   > work, when this works I can look at newer things.   
   Assuming you've copied the VMS headers over to Linux where you are   
   building the compiler, the switch would just be -D_USE_STD_STAT.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)