From: antispam@fricas.org   
      
   Dan Cross  wrote:   
   > In article <109o21i$g12m$1@paganini.bofh.team>,   
   > Waldek Hebisch  wrote:   
   >>Craig A. Berry  wrote:   
   >>> On 9/7/25 1:17 PM, Waldek Hebisch wrote:   
   >>>> [snip]   
   >>>> 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.   
   >   
   > This gets back to my original question: not all code in   
   > libgfortran is created the same.  I doubt that 60-year old code   
   > cares about doing inode number+device equality to determine   
   > uniqueness of a file on a Unix system...particularly as Unix did   
   > not exist 60 years ago.   
   >   
   > Some code _may_ need that.  My guess is that 99.99% wouldn't   
   > care and you can hack it for now to make forward progress.   
      
   ATM I have single unconditional setup.  I made progress,   
   after changing 'st_ino' in header file be an array and   
   small change to gfortran sources gfortran build works.   
      
   >>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.   
   >   
   > You'd just add `-D_USE_STD_STAT` as an additional compiler   
   > argument when building libgfortran, no?   
      
   Unfortunately, within GCC build this is "hard way".  Options   
   are set by configure machinery and this is brittle and time   
   consuming to test.  Comparatively, changes to source files   
   are easy.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)