I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
On 8/29/2025 10:14 AM, Waldek Hebisch wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
I suspect very few try to build VMS executables on Linux.
GNV got both ar and ld, but that does not help you.
But are you sure you want to do it this way?
My understanding is that you want to do:
source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe
I would go for:
source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe
Or if possible even better:
source-(compiler on Linux)->.s-(GCC AS on VMS)->.obj-(LINK on VMS)->VMS .exe
GCC AS (version 2.8) is working on VMS Alpha.
In article <108sckg$19hcn$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
There is a BFD backend for VMS on Alpha in the main binutils
branch in git, but it is not clear to me how well-tested or
generally maintained it is, nor how compatibile with the
standard VMS utilities it ever was; I suspect it existed
primarily to port GNU software to VMS.
What, exactly, are you trying to do?
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/29/2025 10:14 AM, Waldek Hebisch wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
I suspect very few try to build VMS executables on Linux.
GNV got both ar and ld, but that does not help you.
Where are the sources? Working sources certainly would help.
In article <108sckg$19hcn$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
There is a BFD backend for VMS on Alpha in the main binutils
branch in git, but it is not clear to me how well-tested or
generally maintained it is, nor how compatibile with the
standard VMS utilities it ever was; I suspect it existed
primarily to port GNU software to VMS.
What, exactly, are you trying to do?
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/29/2025 10:14 AM, Waldek Hebisch wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
But are you sure you want to do it this way?
My understanding is that you want to do:
source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe
I would go for:
source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe
That is plan B. Working binutils would be simpler because
I could use existing automated process.
Actually, ATM I getting errors during gcc build. I can use
crude workaround to go further, but I am affraid that to get
working compiler I need either working binutils or to examine
all build steps involving binutils and do equvalent work in
different way.
Or if possible even better:
source-(compiler on Linux)->.s-(GCC AS on VMS)->.obj-(LINK on VMS)->VMS .exe >>
GCC AS (version 2.8) is working on VMS Alpha.
Actually, it is possible that I will have to use
source-(compiler on Linux)->.s-(VMS assembler)>.obj...
because one of next goals is to get running compiler wich generate(d) assembly for VMS assembler and may be incompatible with GNU as. But
this means more changes to build process (= work work => not better).
On 2025-08-29, Dan Cross <cross@spitfire.i.gajendra.net> wrote:Not just AdaCore GNAT (Ada).
In article <108sckg$19hcn$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
There is a BFD backend for VMS on Alpha in the main binutils
branch in git, but it is not clear to me how well-tested or
generally maintained it is, nor how compatibile with the
standard VMS utilities it ever was; I suspect it existed
primarily to port GNU software to VMS.
AdaCore was primarily responsible for working on this as part of
GNAT. After they dropped VMS as a supported target, this code may
have gone stale.
I have little faith in ld producing good VMS .exe.
All the GCC ports to VMS I have seen (GCC 1.4x on VAX,
GCC 2.8.x on Alpha and GNAT 2.8.x on Alpha) have used
VMS linker. I suspect they have their reasons.
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/29/2025 10:14 AM, Waldek Hebisch wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
I suspect very few try to build VMS executables on Linux.
GNV got both ar and ld, but that does not help you.
Where are the sources? Working sources certainly would help.
But are you sure you want to do it this way?
My understanding is that you want to do:
source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe
I would go for:
source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe
That is plan B. Working binutils would be simpler because
I could use existing automated process.
Actually, ATM I getting errors during gcc build. I can use
crude workaround to go further, but I am affraid that to get
working compiler I need either working binutils or to examine
all build steps involving binutils and do equvalent work in
different way.
On 8/29/2025 10:14 AM, Waldek Hebisch wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
I suspect very few try to build VMS executables on Linux.
GNV got both ar and ld, but that does not help you.
But are you sure you want to do it this way?
My understanding is that you want to do:
source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe
I would go for:
source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe
Or if possible even better:
source-(compiler on Linux)->.s-(GCC AS on VMS)->.obj-(LINK on VMS)->VMS .exe
GCC AS (version 2.8) is working on VMS Alpha.
On 2025-08-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/29/2025 10:14 AM, Waldek Hebisch wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
But are you sure you want to do it this way?
My understanding is that you want to do:
source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe
I would go for:
source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe
I strongly suspect that will not work as the VMS linker may not
have the features needed to link those .o files.
Or if possible even better:
source-(compiler on Linux)->.s-(GCC AS on VMS)->.obj-(LINK on VMS)->VMS .exe
Er, why ? If you can get the BFD library working for VMS Alpha
once again, that's the major problem sorted.
GCC AS (version 2.8) is working on VMS Alpha.
Also, what makes you think that the GNU gas of that era will still
be suitable for today's compilers ?
On 2025-08-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
All the GCC ports to VMS I have seen (GCC 1.4x on VAX,
GCC 2.8.x on Alpha and GNAT 2.8.x on Alpha) have used
VMS linker. I suspect they have their reasons.
AdaCore started with a cross compiler on Linux.
On 8/29/2025 2:11 PM, Simon Clubley wrote:
On 2025-08-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
All the GCC ports to VMS I have seen (GCC 1.4x on VAX,
GCC 2.8.x on Alpha and GNAT 2.8.x on Alpha) have used
VMS linker. I suspect they have their reasons.
AdaCore started with a cross compiler on Linux.
But did they use ld on Linux or LINK on VMS?
On 2025-08-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/29/2025 1:57 PM, Simon Clubley wrote:
Also, what makes you think that the GNU gas of that era will still
be suitable for today's compilers ?
I would expect Alpha assembler to still be Alpha assembler.
And are you sure that VMS gas 2.8 will support all of the following:
https://sourceware.org/binutils/docs/as/Pseudo-Ops.html
(Those are just the current target-neutral directives).
The instructions are obviously the same.
And I find it unlikely that anyone has spend time the last 25
years adding advanced macros and pseudo instructions to the
Alpha assembler and the compiler.
That's not where the problem is. You need to think at a higher level
than that. Notice that I said today's compilers which may rely on
underlying features not present in that old VMS Alpha version of gas.
On 8/29/2025 1:57 PM, Simon Clubley wrote:
Also, what makes you think that the GNU gas of that era will still
be suitable for today's compilers ?
I would expect Alpha assembler to still be Alpha assembler.
The instructions are obviously the same.
And I find it unlikely that anyone has spend time the last 25
years adding advanced macros and pseudo instructions to the
Alpha assembler and the compiler.
On 2025-08-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/29/2025 10:14 AM, Waldek Hebisch wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
I suspect very few try to build VMS executables on Linux.
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).
GNV got both ar and ld, but that does not help you.
But are you sure you want to do it this way?
My understanding is that you want to do:
source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe
I would go for:
source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe
I strongly suspect that will not work as the VMS linker may not
have the features needed to link those .o files.
Or if possible even better:
source-(compiler on Linux)->.s-(GCC AS on VMS)->.obj-(LINK on VMS)->VMS .exe
Er, why ? If you can get the BFD library working for VMS Alpha
once again, that's the major problem sorted.
GCC AS (version 2.8) is working on VMS Alpha.
Also, what makes you think that the GNU gas of that era will still
be suitable for today's compilers ?
If anyone still has it installed, does the really old GNAT 3.11/3.12p
use ld or the VMS linker ? I know they used gas, but what about the
final link ?
On 8/29/2025 2:44 PM, Simon Clubley wrote:
If anyone still has it installed, does the really old GNAT 3.11/3.12p
use ld or the VMS linker ? I know they used gas, but what about the
final link ?
I have Gnat 3.12p / GCC 2.8.1 installed.
I think it uses LINK.
<quote>
$ gnat make
List of available qualifiers and options
GNAT MAKE file /qualifiers (includes COMPILE /qualifiers)
gnatmake
...
/LINKER_QUALIFIERS (switches for LINK) -largs switches
...
</quote>
It mentions LINK.
On 2025-08-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/29/2025 2:44 PM, Simon Clubley wrote:
If anyone still has it installed, does the really old GNAT 3.11/3.12p
use ld or the VMS linker ? I know they used gas, but what about the
final link ?
I have Gnat 3.12p / GCC 2.8.1 installed.
I think it uses LINK.
<quote>
$ gnat make
List of available qualifiers and options
GNAT MAKE file /qualifiers (includes COMPILE /qualifiers)
gnatmake
...
/LINKER_QUALIFIERS (switches for LINK) -largs switches
...
</quote>
It mentions LINK.
Interesting thanks. Does the "ld" binary exist in whatever the binutils executables directory is ?
If it does, and you run it as a foreign command with "--help", what
output do you get ?
Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <108sckg$19hcn$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
There is a BFD backend for VMS on Alpha in the main binutils
branch in git, but it is not clear to me how well-tested or
generally maintained it is, nor how compatibile with the
standard VMS utilities it ever was; I suspect it existed
primarily to port GNU software to VMS.
What, exactly, are you trying to do?
Well, this is part of bigger rather poorly defined project. ATM
I trying to compile gcc-15.1.
I first build binutils, then I do
../gcc-15.1.0/configure --enable-languages=c,c++ --target=alpha-dec-vms --prefix=/sklad/usr
make -j 7 > mlogg 2>&1
There were earlier problems that I resolved. I have now trouble
during linking of libgcc. Some problems went away after switch
from binutils 2.43 to binutils 2.21. But now I get the following
error:
/sklad/usr/alpha-dec-vms/bin/ld: -shared not supported
That is 'ld' from binutils 2.21 says that it does not support
'-shared'. Note that Makefile wants to create 'libgcc_s.exe',
so it knows about VMS file extentions. In other words somebody
at least tried to make it work.
If you want more details I can provide them, but the message
about '-shared' appears also when I attempt to build a
different shared image:
/sklad/usr/alpha-dec-vms/bin/ld -shared -o pop_poll.exe pop_poll.obj
so the problem can be reproduced outside of gcc build.
On 8/29/2025 3:10 PM, Simon Clubley wrote:
On 2025-08-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/29/2025 2:44 PM, Simon Clubley wrote:
If anyone still has it installed, does the really old GNAT 3.11/3.12p
use ld or the VMS linker ? I know they used gas, but what about the
final link ?
I have Gnat 3.12p / GCC 2.8.1 installed.
I think it uses LINK.
<quote>
$ gnat make
List of available qualifiers and options
GNAT MAKE file /qualifiers (includes COMPILE /qualifiers)
                                                     gnatmake
    ...
    /LINKER_QUALIFIERS (switches for LINK)          -largs switches
    ...
</quote>
It mentions LINK.
Interesting thanks. Does the "ld" binary exist in whatever the binutils
executables directory is ?
If it does, and you run it as a foreign command with "--help", what
output do you get ?
Nothing with ld.
$ dir gnu:[bin]
Directory GNU:[BIN]
AS.EXE;10Â Â Â Â Â Â Â Â Â Â ASISTANT.EXE;1Â Â Â Â Â GCC.EXE;1Â Â Â Â Â Â Â Â Â Â GNAT.EXE;1
GNATBIND.EXE;1Â Â Â Â Â GNATBL.EXE;1Â Â Â Â Â Â Â GNATCHOP.EXE;2Â Â Â Â Â GNATELIM.EXE;1
GNATFIND.EXE;1Â Â Â Â Â GNATKR.EXE;1Â Â Â Â Â Â Â GNATLBR.EXE;1Â Â Â Â Â Â GNATLINK.EXE;1
GNATLS.EXE;1Â Â Â Â Â Â Â GNATMAKE.EXE;1Â Â Â Â Â GNATMEM.EXE;1Â Â Â Â Â Â GNATPREP.EXE;1
GNATPSTA.EXE;1Â Â Â Â Â GNATPSYS.EXE;1Â Â Â Â Â GNATSTUB.EXE;1Â Â Â Â Â GNATXREF.EXE;1
MAKE.EXE;260Â Â Â Â Â Â Â OPENVMS7_1-GCC.EXE;1Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â SET_EXE.COM;11
$ dir gnu:[bin]*ld*.*
%DIRECT-W-NOFILES, no files found
There were earlier problems that I resolved. I have now trouble
during linking of libgcc. Some problems went away after switch
from binutils 2.43 to binutils 2.21. But now I get the following
error:
/sklad/usr/alpha-dec-vms/bin/ld: -shared not supported
That is 'ld' from binutils 2.21 says that it does not support
'-shared'. Note that Makefile wants to create 'libgcc_s.exe',
so it knows about VMS file extentions. In other words somebody
at least tried to make it work.
If you want more details I can provide them, but the message
about '-shared' appears also when I attempt to build a
different shared image:
/sklad/usr/alpha-dec-vms/bin/ld -shared -o pop_poll.exe pop_poll.obj
so the problem can be reproduced outside of gcc build.
On 2025-08-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/29/2025 10:14 AM, Waldek Hebisch wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
I suspect very few try to build VMS executables on Linux.
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).
On 8/29/2025 1:32 PM, Waldek Hebisch wrote:
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/29/2025 10:14 AM, Waldek Hebisch wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
I suspect very few try to build VMS executables on Linux.
GNV got both ar and ld, but that does not help you.
Where are the sources? Working sources certainly would help.
There are the SourceForge version of GNV and there is the
VSI version of GNV.
The SF version is here:
https://sourceforge.net/p/gnv/ld_tools/ci/default/tree/reference/ld_tools/
On 2025-08-29, Waldek Hebisch <antispam@fricas.org> wrote:
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/29/2025 10:14 AM, Waldek Hebisch wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
I suspect very few try to build VMS executables on Linux.
GNV got both ar and ld, but that does not help you.
Where are the sources? Working sources certainly would help.
Aren't they simply wrappers around the native VMS utilities ?
But are you sure you want to do it this way?
My understanding is that you want to do:
source-(compiler on Linux)->.obj->(ld on Linux)->VMS .exe
I would go for:
source-(compiler on Linux)->.obj->(LINK on VMS)->VMS .exe
That is plan B. Working binutils would be simpler because
I could use existing automated process.
Binutils worked at one time because I was able to do the whole
sequence, including generating the final C VMS executable, on Linux.
Actually, ATM I getting errors during gcc build. I can use
crude workaround to go further, but I am affraid that to get
working compiler I need either working binutils or to examine
all build steps involving binutils and do equvalent work in
different way.
That's where I gave up. I either didn't understand the required
VMS-specific build steps or there were bits missing from the public
source kits.
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
Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
That's where I gave up. I either didn't understand the required
VMS-specific build steps or there were bits missing from the public
source kits.
There are missing pieces, build needs VMS header files and libraries.
If those pieces are incomplete, then configuration may go wrong
and lead to trobles later.
Currently I have fairly incomplete set of header files, so I expect
trouble due to this. OTOH libgcc seem to compile fine, so C
compiler probably will work. I worked around trouble with
shared images by configuring gcc with '--disable-shared',
suboptimal but must do for now.
On 8/29/2025 1:57 PM, Simon Clubley wrote:
On 2025-08-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/29/2025 10:14 AM, Waldek Hebisch wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
I suspect very few try to build VMS executables on Linux.
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
Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
When I talked about bits missing, I wasn't thinking about the headers
and libraries. Given that Adacore didn't start using Newlib or something
similar to support VMS, that was pretty much expected.
I was thinking more about bits missing within the compiler or binutils
itself, especially given the crashes I had with Fortran. I was wondering
if, for example, there are bits missing in the image initialisation
sequence, along with other similar types of missing bits.
Do you have any indications that gcc Fortran or C++ worked on VMS say 25 years ago? Presumably Ada Core cared mostly about Ada. To build Ada compiler they needed to build C compiler first. I do not know if they
ever supported on VMS gcc version recent enough to require C++ to build.
If C++ and/or Fortran was never supported, then missing pieces in runtime support are expected. Also, there may be new pieces of platform support needed by newer compiler versions, that nobody bothered to add for VMS.
C and C++ worked in 1.4x on VAX and 2.8.x on Alpha.
The first I remember. I used it pretty extensively.
The second I can demo:
On 2025-08-30, Waldek Hebisch <antispam@fricas.org> wrote:
Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
That's where I gave up. I either didn't understand the required
VMS-specific build steps or there were bits missing from the public
source kits.
There are missing pieces, build needs VMS header files and libraries.
If those pieces are incomplete, then configuration may go wrong
and lead to trobles later.
Currently I have fairly incomplete set of header files, so I expect
trouble due to this. OTOH libgcc seem to compile fine, so C
compiler probably will work. I worked around trouble with
shared images by configuring gcc with '--disable-shared',
suboptimal but must do for now.
If you look at the links Arne posted, you will see I took across to
Linux the VMS-supplied header files inc addition to the libraries.
According to those notes, it appears I also had to write patches
for those headers.
When I talked about bits missing, I wasn't thinking about the headers
and libraries. Given that Adacore didn't start using Newlib or something similar to support VMS, that was pretty much expected.
I was thinking more about bits missing within the compiler or binutils itself, especially given the crashes I had with Fortran. I was wondering
if, for example, there are bits missing in the image initialisation
sequence, along with other similar types of missing bits.
Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
When I talked about bits missing, I wasn't thinking about the headers
and libraries. Given that Adacore didn't start using Newlib or something
similar to support VMS, that was pretty much expected.
I was thinking more about bits missing within the compiler or binutils
itself, especially given the crashes I had with Fortran. I was wondering
if, for example, there are bits missing in the image initialisation
sequence, along with other similar types of missing bits.
Do you have any indications that gcc Fortran or C++ worked on VMS say 25 years ago? Presumably Ada Core cared mostly about Ada. To build Ada compiler they needed to build C compiler first. I do not know if they
ever supported on VMS gcc version recent enough to require C++ to build.
If C++ and/or Fortran was never supported, then missing pieces in runtime support are expected. Also, there may be new pieces of platform support needed by newer compiler versions, that nobody bothered to add for VMS.
On 2025-09-01, Waldek Hebisch <antispam@fricas.org> wrote:
Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
When I talked about bits missing, I wasn't thinking about the headers
and libraries. Given that Adacore didn't start using Newlib or something >>> similar to support VMS, that was pretty much expected.
I was thinking more about bits missing within the compiler or binutils
itself, especially given the crashes I had with Fortran. I was wondering >>> if, for example, there are bits missing in the image initialisation
sequence, along with other similar types of missing bits.
Do you have any indications that gcc Fortran or C++ worked on VMS say 25
years ago? Presumably Ada Core cared mostly about Ada. To build Ada
compiler they needed to build C compiler first. I do not know if they
ever supported on VMS gcc version recent enough to require C++ to build.
If C++ and/or Fortran was never supported, then missing pieces in runtime
support are expected. Also, there may be new pieces of platform support
needed by newer compiler versions, that nobody bothered to add for VMS.
I do not know about Fortran, but C++ used to work IIRC, and Arne
appears to be confirming that as well. I cannot remember if I tried
C++ but I have a vague memory I did and had similar problems to Fortran,
but it's long enough ago that I may be wrong about that.
On 8/29/2025 1:57 PM, Simon Clubley wrote:
On 2025-08-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
On 8/29/2025 10:14 AM, Waldek Hebisch wrote:
I wonder if anybody is using GNU binutils targeting VMS. I am
trying to set up toolchain for cross-compilation (from Linux) to
Alpha VMS. Trying reasonably recent (2.43 and 2.39) binutils I
get errors suggesting serious brokennes, for example when I use
'ar' to create a library and later extract a member I get changed
file and 'objdump' says that extracted file is malformed.
I am now trying binutils 2.21 and apparently they do not have the
problem above. But I see some weirdness and apparently '-shared'
option (to create shared image) is not supported.
I suspect very few try to build VMS executables on Linux.
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
Arne Vajhøj <arne@vajhoej.dk> wrote:VMS EXE is FIX 512, which is FTP binary friendly.
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
On 9/2/2025 8:59 AM, Waldek Hebisch wrote:
...VMS EXE is FIX 512, which is FTP binary friendly.
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 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
VMS OBJ is VAR, which is not FTP binary friendly and FTP
text will likely fuck up the file.
Arne
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 9/2/2025 8:59 AM, Waldek Hebisch wrote:
Arne Vajhøj <arne@vajhoej.dk> wrote:VMS EXE is FIX 512, which is FTP binary friendly.
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 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.
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.
On 9/2/2025 8:59 AM, Waldek Hebisch wrote:
Arne Vajhøj <arne@vajhoej.dk> wrote:VMS EXE is FIX 512, which is FTP binary friendly.
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 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
VMS OBJ is VAR, which is not FTP binary friendly and FTP text will
likely fuck up the file.
On 9/2/25 22:37, Arne Vajhøj wrote:
On 9/2/2025 8:59 AM, Waldek Hebisch wrote:
...VMS EXE is FIX 512, which is FTP binary friendly.
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 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
Check out with "objdump -i" if your objdump supports the VMS object
format for Alpha.
The one I installed from the distributions repository does not. You very likely have to rebuild objdump.
Changing the file attributes or zipping the object file with "-V" will preserve the internal record structure. Works for me:
On Tue, 2 Sep 2025 16:37:12 -0400, Arne Vajhøj wrote:
VMS OBJ is VAR, which is not FTP binary friendly and FTP text will
likely fuck up the file.
No it won’t. The content is still intact, if you do a binary transfer.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 14:30:25 |
| Calls: | 10,389 |
| Files: | 14,061 |
| Messages: | 6,416,903 |