From: arne@vajhoej.dk   
      
   On 9/2/2025 6:30 PM, Waldek Hebisch wrote:   
   > Arne Vajhøj  wrote:   
   >> On 9/2/2025 8:59 AM, Waldek Hebisch wrote:   
   >>> Arne Vajhøj  wrote:   
   >>>> On 8/29/2025 1:57 PM, Simon Clubley wrote:   
   >>>>> A decade ago, I got as far as getting a simple C program for VMS Alpha   
   >>>>> to compile and link on Linux. Anything else more complicated than that   
   >>>>> (ie: other languages) failed and I suspect that either bits were missing   
   >>>>> from the public kits or the additional steps required were not obvious.   
   >>>>>   
   >>>>> I discussed this at length in comp.os.vms at the time. Anyone interested   
   >>>>> will have to rely on the notes I posted at the time as I have completely   
   >>>>> forgotten the details of any of this (and have no motivation to get back   
   >>>>> up to speed on them because my hobbies these days are very different and   
   >>>>> because there's no longer a proper hobbyist licence for VMS Alpha).   
   >>>>   
   >>>> I did the search:   
   >>>>   
   >>>> https://groups.google.com/g/comp.os.vms/c/KN9yqM7_8PU/m/T4xwyTz5A3oJ   
   >>>>   
   >>>> https://groups.google.com/g/comp.os.vms/c/S7-VwQmmOZU/m/LXQ2TrbCBAAJ   
   >>>>   
   >>>> https://groups.google.com/g/comp.os.vms/c/oSNzXLKeu4o/m/8Tq5dIFaDAAJ   
   >>>   
   >>> I looked deeper at the last message (one with 8Tq5dIFaDAAJ at the end).   
   >>> The fix for PR 17512 is clearly wrong: 'struct vms_eihd' is deliberatly   
   >>> bigger than typical headers.  Reverting this and similar fix for   
   >>> PR 21813 allows objdump from binutils-2.39 to disassemble VMS shared   
   >>> images with small header.  However, cross binutils-2.39 can not read   
   >>> VMS object files, and any attempts at linking give result like:   
   >>>   
   >>> foo.obj: file not recognized: file format not recognized   
   >> VMS EXE is FIX 512, which is FTP binary friendly.   
   >>   
   >> VMS OBJ is VAR, which is not FTP binary friendly and FTP   
   >> text will likely fuck up the file.   
   >>   
   >> I would:   
   >> * $ SET FILE/ATTR=(RFM:FIX,MRS:512) on the OBJ file on VMS   
   >> * FTP binary to Linux   
   >> * see if objdump on Linux can recognize it   
   >   
   > I di this before writing my previous message.  objdump from   
   > binutils-2.21 recognizes both files produced by gas from binutils-2.21   
   > and file transferred from VMS (after doing what you wrote).  After   
   > transfering .obj file produced by binutils-2.21 from Linux to   
   > VMS (which was tricky) ANALYZE said that it constins no   
   > errors.  Transferring was tricky, becuse transfer via scp gave   
   > fixed 512 bytes blocks.  Doing SET FILE/ATTR=RFM:VAR resulted in   
   > null padding at the end and ANALYZE were complaining about   
   > empty records (but no other errors).  zipping .obj file, transfering   
   > that to VMS gave streamlf file.  Doing SET FILE/ATTR=RFM:VAR on   
   > this file apparently worked.  But zip treating it as text file   
   > can potentially mangle it, so I am looking for better method.   
      
   I think I would go for:   
   * FTP binary from Linux to VMS   
   * SET FILE/ATTR=RFM:VAR on it   
      
   And if padding gives problems, then:   
   * SET FILE/ATTR=(EFBLK:n,FFB:m) on it   
      
   > Anyway, objdump from binutils-2.39 can not recognize .obj files   
   > produced by gas from binutils-2.21 (which due to tests above I   
   > believe have correct format).  Also, using gas from binutils-2.39   
   > or binutils-2.43 I get similar results.   In other words,   
   > objdump from binutils-2.21 recoginzes .obj files regardless of   
   > source (tranferred from VMS or made by gas from any binutils).   
   > objdump from later binutils does not recognize .obj files   
   > from above mentioned sources.   
      
   VMS Alpha support missing in newer versions??   
      
   Arne   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)