From: antispam@fricas.org
Arne Vajhøj wrote:
> 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
Thank, after replacing EFBLK by EBK this works for me.
>> 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??
Everthing from old versions is present. There are also some fixes.
AFAICS this is just normal bitrot due to inadeqate testing.
--
Waldek Hebisch
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
