[Info-vax] What would you miss if DECnet got the chop? Was: "bad select 38" (OpenSSL on VMS)

[Simon Clubley]

On 2016-09-20, Chris <xxx.syseng.yyy at gfsys.co.uk> wrote:
> On 09/20/16 17:17, Stephen Hoffman wrote:
>
>>
>> fork() is not available on OpenVMS, and has little direct relationship
>> to the socket API. Code that uses fork() can range from fairly easy to
>> port, to basically impossible. The stuff that's easy to port doesn't
>> really use fork(), so it can be replaced with some combination of the
>> vfork() and exec() calls.
>>
>
> Of course, i'm years out of date, but doesn't VMS have a spawn system
> call to set of a new new process ? I guess the question being if
> a spawned process inherits the parent environment or not.
>

It's the whole cloning the process thing which fork() does that VMS
has an issue with.

That's why Stephen is saying simple to impossible because depending
on the program, some of the actual fork() usage can be done with a
simple spawn and some of it needs the full fork() functionality.

>
>>
>> I'd tend to expect that approach would add as many complications as
>> it'll remove. While there are gcc ports around, gcc is gcc and
>> self-contained not really tied into any of the underlying interfaces and
>> tools on the target platform, and OpenVMS is rather more different from
>> most GNU/Linux boxes. Off-hand, I don't know if gcc is tied into the
>> OpenVMS debugger, into the threading libraries, or other pieces of the
>> environment, for instance.
>
> I only ask that question because much (most?) open source
> software assumes a gcc environment, gnu make and all the
> other gnu utilities already installed, of which there are
> many. Gcc has it's own specific command line arguments,
> extensions etc, which are unlikely to be compatible with
> other compilers and you really want avoid delving into the
> Makefiles if you can avoid it. Having built gcc and other
> utils from time to time, I can tell you that you would not
> want to go near some of the Makefiles, which can induce
> brain damage on sight :-), but that would be needed if
> gcc etc is not in place.
>

Let me guess: you've built gcc based cross compilers ? :-)
Been there, done that, many times (both with RTOS targets and bare
metal as well as normal native gcc builds) so I'm familiar with
the issues involved unfortunately.

The clang driver does have a (mostly) gcc compatible command line
so it helps in moving your own build environment from gcc to LLVM.

> Overall, not an easy task I guess. Fwics, gcc for VMS was
> dropped years ago, not a good omen. Don't know if it
> could be used to bootstrap later versions. I guess you
> could cross compile from a Linux or similar os to Itanium,
> which works very well on some architectures used here.
>

This is where it gets complicated.

Yes, the original gcc port for VMS fell into disuse many years ago,
but DEC and then HP contracted with Adacore to provide Ada
(in the form of GNAT) on VMS Alpha and then VMS IA64.

This meant Adacore have done their own port of gcc/binutils to
VMS Alpha and IA64. Unfortunately, that lives in their own private
version of the gcc code base and while they have pushed some of it
to the FSF gcc/binutils code base, there wasn't enough of it as at
a couple of years ago to build the current gcc/binutils at the
time for VMS.

Note that this is fully GPL compliant; Adacore are using the
option in the GPL which only requires them to supply the source
code to any customers receiving their VMS binaries (ie: their
paying VMS customers).

> In fact, a cross compile environment might be the best way
> to go, hosted on Linux, FreeBSD, etc on X86, cross
> compiled to an Itanium target. Same for binutils and make.
> Doesn't solve the problem of run time interface to VMS,
> but it would be a start just to be able to generate Itanium
> binaries using a gcc compiler tool chain.
>

That's exactly how I tried to bootstrap the FSF gcc/binutils
code base for VMS; I used Linux as the cross compiler host
and tried a cross compiler build for VMS Alpha.

I tried four of the gcc frontends when building the cross compiler:
Ada, C, C++ and Fortran. C was the only one I was able to build
usable VMS binaries for with the cross compiler. Both the Ada and
C++ frontends failed to compile while building the cross compiler
itself and a simple Fortran test program built but fell over during
image activation (or very shortly afterwards; I can't remember).

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world