So I finally got around to bringing up a v9.1-A system and took a swing
at trying to build something with the cross tools on Itanium. The docs
for those tools mention SYS$MANAGER:X86_XTOOLS$SYLOGIN.COM, which, among
other things, "Adds the cross-tools specific command definitions to the
CLI table of a process."

So far so good. You wouldn't want to mangle your system command tables
on your Itanium system if you were still trying to target Itanium some
of the time. But, as far as I can see, CLD definitions -- unlike logical
names and symbols -- are not inherited by subprocesses. Is that really
true?

Here is my conundrum:

$ show symbol cc
CC == "XCC"
$ cc/vers
VSI C X7.4-528 (GEM 50V6F) for X86 on OpenVMS IA64 V8.4-2L3
$ xcc/vers
VSI C X7.4-528 (GEM 50V6F) for X86 on OpenVMS IA64 V8.4-2L3
$ mmk
CC/DECC/NOANSI_ALIAS
/Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList/float=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=(PERL_CORE,_USE_STD_STAT=1)
PERLMINI.C
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\XCC\
%MMK-F-ERRUPD, error status %X00038090 occurred when updating target
PERLMINI.OBJ

Clearly the symbol definition does what's on the tin and runs the XCC
command when CC is invoked, and clearly the process I'm starting from
knows what the XCC command is. But when MMK creates a subprocess to run
a command, that process has no idea what XCC means.

Surely I am not the first person to encounter this. Any real-world
build system using MMS or MMK would encounter the same thing. Do I
really have to hack up the command definitions to stuff the cross tools
commands into the system table, and then figure out how to unstuff them
later when I want to target Itanium rather than x86_64?

On 2021-10-17, Craig A. Berry <craigberry@nospam.mac.com> wrote:
>
> Surely I am not the first person to encounter this. Any real-world
> build system using MMS or MMK would encounter the same thing. Do I
> really have to hack up the command definitions to stuff the cross tools
> commands into the system table, and then figure out how to unstuff them
> later when I want to target Itanium rather than x86_64?

Can you create a custom DCLTABLES for your account (call it CRAIGDCL
or something similar), and have that as your login DCL command table
using AUTHORIZE ?

Look at SET COMMAND/REPLACE and SET COMMAND/OUTPUT for ideas.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 10/17/2021 7:49 PM, Craig A. Berry wrote:
> So I finally got around to bringing up a v9.1-A system and took a swing
> at trying to build something with the cross tools on Itanium.  The docs
> for those tools mention SYS$MANAGER:X86_XTOOLS$SYLOGIN.COM, which, among
> other things, "Adds the cross-tools specific command definitions to the
> CLI table of a process."
>
> So far so good.  You wouldn't want to mangle your system command tables
> on your Itanium system if you were still trying to target Itanium some
> of the time. But, as far as I can see, CLD definitions -- unlike logical
> names and symbols -- are not inherited by subprocesses.  Is that really
> true?
>
> Here is my conundrum:
>
> $ show symbol cc
>   CC == "XCC"
> $ cc/vers
> VSI C X7.4-528 (GEM 50V6F) for X86 on OpenVMS IA64 V8.4-2L3
> $ xcc/vers
> VSI C X7.4-528 (GEM 50V6F) for X86 on OpenVMS IA64 V8.4-2L3
> $ mmk
> CC/DECC/NOANSI_ALIAS
> /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList/float=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=(PERL_CORE,_USE_STD_STAT=1)
> PERLMINI.C
> %DCL-W-IVVERB, unrecognized command verb - check validity and spelling
>  \XCC\
> %MMK-F-ERRUPD, error status %X00038090 occurred when updating target
> PERLMINI.OBJ
>
> Clearly the symbol definition does what's on the tin and runs the XCC
> command when CC is invoked, and clearly the process I'm starting from
> knows what the XCC command is.  But when MMK creates a subprocess to run
> a command, that process has no idea what XCC means.
>
> Surely I am not the first person to encounter this.  Any real-world
> build system using MMS or MMK would encounter the same thing.  Do I
> really have to hack up the command definitions to stuff the cross tools
> commands into the system table, and then figure out how to unstuff them
> later when I want to target Itanium rather than x86_64?

Two ideas:
* maybe MMK can be convinced to @ that COM file as the first thing in
the subprocess
* create a X64DCLTABLES and create an account X64CRAIG with that
as default CLITABLES

Arne

I don't know if this will solve your problem (I'm not familiar with MMK), but for MMS we use the .FIRST directive to run a command procedure which, among other things, runs a setup command procedure for "tools" (worked fine in the IA64 port, haven't tried it yet for x86)

On 10/17/2021 8:56 PM, Bob Wilson wrote:
> I don't know if this will solve your problem (I'm not familiar with MMK), but
> for MMS we use the .FIRST directive to run a command procedure which, among
> other things, runs a setup command procedure for "tools" (worked fine in the
> IA64 port, haven't tried it yet for x86)

Using the .FIRST directive in MMS works with the IA64-based X86 cross-tools
compilers.

--
-- Rob

On 10/18/21 4:06 AM, Robert A. Brooks wrote:
> On 10/17/2021 8:56 PM, Bob Wilson wrote:
>> I don't know if this will solve your problem (I'm not familiar with
>> MMK), but
>> for MMS we use the .FIRST directive to run a command procedure which,
>> among
>> other things, runs a setup command procedure for "tools" (worked fine
>> in the
>> IA64 port, haven't tried it yet for x86)
>
> Using the .FIRST directive in MMS works with the IA64-based X86
> cross-tools compilers.
>

Yes, command tables are not propagated to spawned subprocesses. This
affects MMS/MMK.

As mentioned, there is a .FIRST for MMS/MMK, you should have the cross
tools setup in the .FIRST. If you don't want to change the existing
makefile, ahem description file, you can concatenate a "first" file with
your existing one: /DESCRIPTION=("DESCRIP+FIRST"). Yes, quoted. This
works for MMS. I can't get that to work for MMK. Here you may need
something like "$ pipe type/noheader descrip.mms+first.mms |
mmk/descr=sys$pipe". For MMS there can be only one first in the
concatenated description. That explains my order of the plus list. The
last one wins. For MMK you can have several, all seem to be executed. If
you use MMS and already have a .FIRST in your DESCRIP.MMS, you may need
to copy the actions from that to the "first" description file.

On Sunday, October 17, 2021 at 8:03:46 PM UTC-4, Simon Clubley wrote:
> Can you create a custom DCLTABLES for your account (call it CRAIGDCL
> or something similar), and have that as your login DCL command table
> using AUTHORIZE ?

If you want to switch back and forth between native build and cross build,
that doesn't solve anything. x86_tools$sylogin.com does more to your
environment than just modify the command tables (i.e. sets logicals and
DCL symbols).

I had the problem that my build creates an executable that needs to be
run as part of the build. The MMS file had to recognize when I was in the
cross build environment, then selectively undo the changes to the CC and
LINK commands in order to get a native build of just that image.

On 10/18/21 4:41 AM, hb wrote:
> On 10/18/21 4:06 AM, Robert A. Brooks wrote:
>> On 10/17/2021 8:56 PM, Bob Wilson wrote:
>>> I don't know if this will solve your problem (I'm not familiar with
>>> MMK), but
>>> for MMS we use the .FIRST directive to run a command procedure which,
>>> among
>>> other things, runs a setup command procedure for "tools" (worked fine
>>> in the
>>> IA64 port, haven't tried it yet for x86)
>>
>> Using the .FIRST directive in MMS works with the IA64-based X86
>> cross-tools compilers.

Thanks for all the replies. Yes, .FIRST works for simple cases and when
MMS or MMK is the thing spawning the compile command.

> Yes, command tables are not propagated to spawned subprocesses. This
> affects MMS/MMK.

And anything else that does a compile or link in a subprocess.

> As mentioned, there is a .FIRST for MMS/MMK, you should have the cross
> tools setup in the .FIRST. If you don't want to change the existing
> makefile, ahem description file, you can concatenate a "first" file with
> your existing one: /DESCRIPTION=("DESCRIP+FIRST"). Yes, quoted. This
> works for MMS. I can't get that to work for MMK. Here you may need
> something like "$ pipe type/noheader descrip.mms+first.mms |
> mmk/descr=sys$pipe". For MMS there can be only one first in the
> concatenated description. That explains my order of the plus list. The
> last one wins. For MMK you can have several, all seem to be executed. If
> you use MMS and already have a .FIRST in your DESCRIP.MMS, you may need
> to copy the actions from that to the "first" description file.

That's all impressive and scary. Luckily editing .FIRST or the code
that generates it to include the cross tools set-up got me as far as I
can get with that mechanism. Then I was on to cases where code is
generated that needs to be compiled and run natively to probe for
features that will then be used to generate additional code that will
need to be built with the cross tools. It's not going to be pretty.
But the weekend is over and I'm back to doing real work :-(.

On Monday, October 18, 2021 at 12:10:04 PM UTC-4, Craig A. Berry wrote:
> That's all impressive and scary. Luckily editing .FIRST or the code
> that generates it to include the cross tools set-up got me as far as I
> can get with that mechanism. Then I was on to cases where code is
> generated that needs to be compiled and run natively to probe for
> features that will then be used to generate additional code that will
> need to be built with the cross tools. It's not going to be pretty.

My solution certainly isn't pretty:
! ! Ensure when in crossbuild mode that generate_options is still native. The
! IA64 image is still built in the [.X86_64] directory so we don't have to change
! references to $(ARD)generate_options.exe in other dependency rules.
! Macros:
! AR_MODE XBUILD or NATIVE
! ARD Sub-directory for architecture-specific targets (e.g. [.IA64]).
! ..if $(AR_MODE) .eq XBUILD
[-.X86_64]generate_options.exe : [.X86_64]generate_options.obj
link_image = f$trnlnm("IA64_LINK","LNM$PROCESS")
deassign IA64_LINK ! undo X86_TOOLS re-definition
link /exec=[-.X86_64]generate_options.exe [-.X86_64]generate_options.obj
define IA64_LINK 'link_image' ! restore X86_TOOL re-definition

[-.X86_64]generate_options.obj : generate_options.c
go_cc = f$extract(1,f$length(cc)-1,cc) ! Change XCC to CC
go_cc $(cflags)/pointer_size=short generate_options.c /object=[-.X86_64]generate_options.obj

..else
$(ARD)generate_options.exe : $(ARD)generate_options.obj
link /exec=$(ARD)generate_options.exe $(ARD)generate_options.obj

$(ARD)generate_options.obj : generate_options.c
cc $(cflags)/pointer_size=short generate_options.c /object=$(ARD)generate_options.obj

..endif

It would be even worse if I had to worry about 64-bit being an option.

On 10/18/2021 12:51 PM, David Jones wrote:
> On Monday, October 18, 2021 at 12:10:04 PM UTC-4, Craig A. Berry wrote:
>> That's all impressive and scary. Luckily editing .FIRST or the code
>> that generates it to include the cross tools set-up got me as far as I
>> can get with that mechanism. Then I was on to cases where code is
>> generated that needs to be compiled and run natively to probe for
>> features that will then be used to generate additional code that will
>> need to be built with the cross tools. It's not going to be pretty.
>
> My solution certainly isn't pretty:

[...] stuff removed

That seems more complicated than it needs to be

You can remove the cross-build changes this way . . .

@sys$startup:X86_XTOOLS$SYLOGIN.COM "" "" "TRUE"

I also build a few layered products whose bootstrap tools need to run
on the build system, so I'm constantly flipping between native and
cross builds in the context of a build.

--

-- Rob

On 2021-10-18, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
> On 10/18/2021 12:51 PM, David Jones wrote:
>> On Monday, October 18, 2021 at 12:10:04 PM UTC-4, Craig A. Berry wrote:
>>> That's all impressive and scary. Luckily editing .FIRST or the code
>>> that generates it to include the cross tools set-up got me as far as I
>>> can get with that mechanism. Then I was on to cases where code is
>>> generated that needs to be compiled and run natively to probe for
>>> features that will then be used to generate additional code that will
>>> need to be built with the cross tools. It's not going to be pretty.
>>
>> My solution certainly isn't pretty:
>
> [...] stuff removed
>
> That seems more complicated than it needs to be
>
> You can remove the cross-build changes this way . . .
>
> @sys$startup:X86_XTOOLS$SYLOGIN.COM "" "" "TRUE"
>
>
> I also build a few layered products whose bootstrap tools need to run
> on the build system, so I'm constantly flipping between native and
> cross builds in the context of a build.
>

Disclaimer: I am more familiar with the gcc approach to building
and using embedded toolchains than I am with the LLVM approach
to building them.

However, I am aware that clang uses target triples to select the
target. Do the VSI cross-compiler toolchains also use target triples
underneath the DCL commands ?

If so, is there any possibility of just invoking the tools directly,
bypassing the DCL commands, and specify the target triple for x86-64
VMS on the command line directly ?

If you could do that, then it may be one way to run both the native
compilers and cross-compilers in one session without having to switch
between them. I've found the following clang documentation for selecting
the target triple:

https://clang.llvm.org/docs/CrossCompilation.html

in case anyone wants to read up about target triples.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

re: @sys$startup:X86_XTOOLS$SYLOGIN.COM "" "" "TRUE"

I think that this only DEASSIGNs the logical names (i.e. the CLD changes are still in effect [which may be incompatible with the native/locally-installed stuff]... you may need to do something like SET COMMAND /TABLE=SYS$LIBRARY:DCLTABLES.EXE to get the default command definitions back)

On 10/18/21 12:38 PM, Simon Clubley wrote:
> On 2021-10-18, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
>> On 10/18/2021 12:51 PM, David Jones wrote:
>>> On Monday, October 18, 2021 at 12:10:04 PM UTC-4, Craig A. Berry wrote:
>>>> That's all impressive and scary. Luckily editing .FIRST or the code
>>>> that generates it to include the cross tools set-up got me as far as I
>>>> can get with that mechanism. Then I was on to cases where code is
>>>> generated that needs to be compiled and run natively to probe for
>>>> features that will then be used to generate additional code that will
>>>> need to be built with the cross tools. It's not going to be pretty.
>>>
>>> My solution certainly isn't pretty:
>>
>> [...] stuff removed
>>
>> That seems more complicated than it needs to be
>>
>> You can remove the cross-build changes this way . . .
>>
>> @sys$startup:X86_XTOOLS$SYLOGIN.COM "" "" "TRUE"
>>
>>
>> I also build a few layered products whose bootstrap tools need to run
>> on the build system, so I'm constantly flipping between native and
>> cross builds in the context of a build.
>>
>
> Disclaimer: I am more familiar with the gcc approach to building
> and using embedded toolchains than I am with the LLVM approach
> to building them.
>
> However, I am aware that clang uses target triples to select the
> target. Do the VSI cross-compiler toolchains also use target triples
> underneath the DCL commands ?
>
> If so, is there any possibility of just invoking the tools directly,
> bypassing the DCL commands, and specify the target triple for x86-64
> VMS on the command line directly ?

The target triples seem very specific to clang and related front ends.
Given that the front ends for all the cross compilers are ports of the
existing VMS front ends and all of them have been made to believe there
is something resembling GEM under the hood even though it's a
GEM-to-LLVM compatibility layer, what you're suggesting sounds highly
improbable.

On Monday, October 18, 2021 at 1:01:13 PM UTC-4, Robert A. Brooks wrote:
> That seems more complicated than it needs to be
>
> You can remove the cross-build changes this way . . .
>
> @sys$startup:X86_XTOOLS$SYLOGIN.COM "" "" "TRUE"
>

That doesn't seem to undo the "CC :== XCC" DCL symbol assignment,
at least on revision X44.24-XG1E.