Two C++ compilers on one cluster

[Piet Timmers_1]

ls.

Is it possible to install more C++ compilers on a single (or cluster) system.
Here they want to install C++ V6.5 and C++ V7.1 on the same node.

I adviced not to do, but some people are very cocky.

Greetings,

Piet Timmers

[Karl Rohwedder]

As fas as I know, you can even install multiple versions on one system, a procedure sys$system:cxx$show_version shows the installed versions, cxx$set_version activates one version for you.

The CXX installation kit asks if you want to retain an older version.

regards Kalle

[Willem Grooters]

Installing compilers is not "daily business" so I have to rely on memory.

Compilers are, AFAIK, directly installed on [VMS$COMMON] and subsequent directories (SYSEXE, SYSLIB). In that respect, the answer is NO, unless, in a cluster nvironment, run systems from a local system disk. That means: each node has it's own installation of C++, and that can be different versions.

in the past, I have tried installing compilers on a different location, and in that case, directory [VMS$COMMON] and subsequent directories will be created, on that location. To get this running, you'll need to redefine a number of system logicals to include these locations. However, OpenVMS activity is very much depending on these logicals so the slightest mastake will render the system ununsable, or worst case: inaccessable.
I found it _might_ work for compilation but it did severely interfere with linking the program (unresolved references) that did not occutr after teh compiler was installed "properly"

So the answer is: it MIGHT be possible but it is VERY VERY UNWISE to do so.

(Suggestion: take a (small) machine to run the separate compiler. You may thiink of Alpha emulation on a PC as well.

[Karl Rohwedder]

Just had a look into the CXX-installguide, see section 2.1:

excerpt:

2.1 Installing and Using Multiple Compiler Versions

C++ Version 7.1 provides support for installing and using
multiple versions of the compiler on the same node.
...

regards kalle

[Kris Clippeleyr]

Piet,
AFAIK, having 2 versions of the C++ compiler sitting next to one another is supported (we have several development systems that have the 6.5 and the 7.x variant).
Karl is correct about the command procedures.
The installation procedure of the (newer) C++ compiler also asks which version is to be the default.
Regards,
Kris (aka Qkcl)

[John Gillings]

Piet,

Compilers are unprivileged usermode programs that really just process a text file. You can have as many versions of a compiler as you can fit in storage, and since they tend to be relatively small that's rarely an issue. I recommend you keep copies of ALL versions of all compilers.

If you happen to find a problem with a particular compiler, you can easily revert to an older compiler. Remember that it is NOT necessary to have all modules linked into a simple program compiled with the same version of compiler.

Some compiler kits include multiversion support. C and Pascal certainly do with SHOW_VERSION and SET_VERSION command procedures, but really all they do is flip a few logical names around. When installing a new compiler, say NO to the question about purging files replaced. You may also want to rename the compiler image to include the version number, just to make things clear.

Another thing you can do is pull the compiler images out of a kit into your own private directory and define logical names to use a newer version of a compiler without actually installing it. This means if you have a problem with your current compiler, you can quickly check if it's fixed in a later version without making it system wide. Again, this is non-privileged, usermode, so if you have just one "cocky" person who wants a different compiler from everyone else, you can give them the one they want.

[Hoff]

While Linus has had some incendiary remarks about C++ of late, these folks really seem to like an extra helping of complexity by instantiating the compiler itself. But yes, you can implement that -- with HP support -- with recent C and C++ compilers.

An organization I'm familiar with keeps large numbers of compilers on hand and has done so for many years -- one or more sets of tools for each software release is kept on-hand -- and the requisite compiler build is activated via its CLD and logical name when work on the release is required. This long before formal support in the compilers arrived.

As for rolling your own, this is an approach likely wholly unsupported by HP, but usually easy enough to figure out. You'll often need to include compiler-provided libraries and related and ancillary pieces in the package, of course.

[Jan van den Ende]

Piet,

Your profile:
>>>
I have assigned points to 66 of 103 answers of my questions
<<<

Is het geen tijd om
http://forums1.itrc.hp.com/service/forums/pageList.do?userId=BR815919&listType=unassigned&forumId=1
eens langs te lopen, en de "unassigned"s te verhelpen.
En ook 0 (nul) is een mogelijk assign...

Groetjes.

Proost.

Have one on me.

jpe

[Willem Grooters]

Never too old to learn :)

The point that I ran into (no C++ nor Pascal) was just seeting these logicals. If the packages contains a SET_VERSION to take care of that - that's fine. Without knowing what logicals to floip, it's more troublesome - and it took me far to much time to figure it all out.