From: cross@spitfire.i.gajendra.net   
      
   In article <109rl2h$r2qr$1@paganini.bofh.team>,   
   Waldek Hebisch  wrote:   
   >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.   
      
   Odd.  Usually the `autoconf` stuff gives you the option of   
   adding extra flags for the C compiler with a switch to the   
   `configure` script that it generates.  Something like,   
      
   `./configure --extra-cflags='-D_USE_STD_STAT' --whatever ...`   
      
   It seems like that'd be a lot more robust.  But as I said   
   earlier, I'm not the one swinging the hammer here....   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)