[Info-vax] Update Kit for OpenVMS 9.1 released today

[John Reagan]

On Monday, August 23, 2021 at 6:39:20 AM UTC-4, Joukj wrote:
> John Reagan wrote: 
> > 
> > But in general, you can move things back and forth easily. You can take OpenVMS-created objects and link/execute them on Linux. The other way works as well (that is how we bootstrapped a recent clang/LLVM to OpenVMS x86).
> Sound interesting and easy, but I suspect a lot of pitfalls: i.e. what 
> happens if you compile a fork implementation on linux and link it on 
> OpenVMS? 
> 
> Jouk
A compiler on Linux sees a call to an external routine named "fork".  It is placed in the ELF symbol table as an external name.  Bring it to OpenVMS and the linker looks for a routine named "fork".  It won't find it.  You'll get an error message.  Feel free to write you own routine named "fork".

The more interesting cases are CRTL names.  On Linux, call "printf".  The external name in the ELF symbol table is "printf".  We don't have just a "printf" on OpenVMS,  We prefix the names and have multiple versions due to all the different floating types.  You'll see things like DECC$TXPRINTF.  The C/C++ frontends on OpenVMS do that name mapping for you.  The Linux compilers don't know about it.  You either need lots of funky #define's, shim routines, or actually put some name mapping into the Linux compiler (we added crude name mapping).

You also have to watch what headers you use.  The default set of Linux headers might allow certain names to be declared and used but those features might not be on OpenVMS.  Our bootstrapping used a mixture of OpenVMS headers and Linux headers.

Going the other way, you just tell the C compiler not to prefix anything.  We've compiled several files using the Itanium-hosted/x86-target C compiler (with no prefixing) and moved that .obj file to Linux to link and execute.