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

[John E. Malmberg]

On 9/21/2016 10:48 AM, Stephen Hoffman wrote:
> On 2016-09-20 21:06:53 +0000, Chris said:
>
>> On 09/20/16 17:17, Stephen Hoffman wrote:
>>

>> 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.
>
> It's less about make — GNU make is available on OpenVMS — and more about
> the GNU expectations of autoconf and configure et al.

Be a little careful with make.  There are two very different GNU makes 
out there for VMS.

GNV Make is an older fork of GNU Make that is hacked to only work with 
Bash and use Unix syntax makefiles.

GNU Make has a VMS mode that pretty much currently supports its own 
special syntax of makefiles.  This syntax is a mashing of DCL and UNIX 
syntax.  It can can not handle most Unix syntax makefiles.

I plan to eventually merge the GNV make features back into the upstream 
GNU make.  That requires fixing more issues with that GNU make running 
on VMS.  Locally the self tests for GNU Make are now runable on VMS, I 
just have not had time to negotiate getting the test changes merged in.

> It's now
> possible to run GNU configure scripts on OpenVMS, but that still
> requires tweaking the scriptsand getting them tailored to work with
> what OpenVMS provides.

I do not edit the configure scripts or the resulting makefiles.  I add 
"helper" files such as option, first include files, and command files 
that the GNV tools know to look for and use.

> The need to tweak these configure scripts
> and/or the source code when porting across disparate Unix systems is not
> particularly unusual, either.
>
> More than a little of this — what allows the configure scripts to run —
> was code that John got working and is maintaining, too.

>> 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.

GCC/VAX and Alpha maintenance effectively stopped when DECC became 
available to hobbyists.  Somewhere I hopefully have copies of the last 
known source for both.  GCC/VAX along the way lost the current source to 
the GCC.exe image.

GCC/Itanium claims support for VMS in is current man pages.

> There's code tied pretty tightly to gcc, but I've seen rather less of
> that than of code that's tied to some specific feature of GNU or Linux.

The Python 3.x configure script requires that the C compiler implement 
at least one GCC specific extension to tell it some information.

> Ask questions.   Ask for documentation or pointers to tools or
> resources.    Twenty year old assumptions and recollections might still
> work — this is OpenVMS, after all — or they might not.   Get Python and
> GNV and the GNV updates installed.

You can just install the GNV updated kits with out the full GNV kit. 
The updates alone are good enough to handle many configure/makefile 
sequences now.

If you are going to install the full GNV kit, it needs to be installed 
before the update.

Or you may want to wait until the bootcamp.  I suspect there will be 
some sort of update.

>   Go port some code.  Maybe read some
> notes from and listen in on some of the porting calls.  Search through
> postings here in comp.os.vms newsgroup via the Google Groups
> archives.    OpenVMS doesn't have an open source community of any size,
> so it'll be pretty easy to get to know most folks involved, and what's
> going on...

The GNV and vms-ports projects are way below the number of active 
contributors that are really needed for them.

It would be nice to see if someone could take the time to organize the 
hacks that are being used to build from unmodified upstream source code 
to VMS binaries into a set of alternate header file TLBs and and an add 
on library.

The alternate header file TLB could make many of the hacks completely 
transparent to the build system.

Regards,
-John
wb8tyw at qsl.net_work