Re: OpenVMS first test run report summary

[John E. Malmberg]

On 7/19/2017 8:31 AM, John E. Malmberg wrote:
> ============================================================================ 
>
> Testsuite summary for dummy 0
> ============================================================================ 
>
> # TOTAL: 1146
> # PASS:  874
> # SKIP:  99
> # XFAIL: 0
> # FAIL:  173
> # XPASS: 0
> # ERROR: 0

A number of OpenVMS C library routines are setting errno incorrectly. 
This has been reported to HPE and VSI.  I should be able to work around 
this.

On OpenVMS, "", and "." are legal native filenames and are actually the 
same filename, so opening "" or "." for writing will succeed.  I have to 
see if the feature setting to only use Unix filenames disables this 
behavior.

Some tests depend on the Unix expected behavior of getdtablesize so are 
failing.

Those should not take much to fix.

Some of the long double tests are failing.  I have not determined the 
exact cause.  Next full compile run will have some extra floating point 
diagnostics enabled.

Many of the unicode tests are failing.  Still have not investigated them.

The PATH_MAX macro in the OpenVMS provided limits.h applies only to 
ODS-2 volumes and is too small.  It should be 4096.  I suspect I will 
find other bugs in that file.

The gnulib getcwd() does not work on OpenVMS and seems to always return 
NULL.  This prevents the <xxx>at() routines from working.  Probably some 
other stuff will be needed for <xxx>at() routines, but that is a start.

The OpenVMS getcwd() has 2 bugs of importance to gnulib.

  1. x = getcwd(NULL, 0) fails.
  2. x = getcwd(buffer, size, 0) fails when the current
     working directory real path is more than 4096 on ODS-5 volumes.

The first bug is worked around with a trivial wrapper.

The second bug requires having getcwd() return the current
directory in OpenVMS format, which OpenVMS will shorten to DID notation, 
and then use a special vms_to_unix_filename conversion routine to 
convert it back to Unix format.

While this gets the getcwd() working, other portions of the OpenVMS,
using real deep paths may expose other bugs in the C library.

Configure is detecting an issue with the OpenVMS provided realpath() 
that I need to investigate.  The gnulib realpath() replacement has no 
hope of working on OpenVMS.  I should be able to come up with a way to 
get the OpenVMS realpath() to work, and have an algorithm to simulate 
realpath() on OpenVMS releases before 8.3, when realpath() and symlinks 
were added.

For getprogname, I generally put a wrapper around main(), and have it 
set a variable that an OpenVMS specific getprogranme returns.  This is 
especially needed for GNU Make because I need the unmodified argv[0] in 
order to set up for recursive make to work corrrectly, and the stuff I 
do to set that up is mostly the same parsing needed for getprograme.

For system() and popen() I have OpenVMS specific replacements, the 
popen() replacement is using the vm_pipe code I mentioned earlier.

The OpenVMS poll() and select() are also going to need a bit of OpenVMS 
specific code to make them work as expected.

This will probably keep me busy for a little while, so what I would like 
to know is should I be looking at adding addtional OpenVMS modules to 
the [.lib] or keeping them in a separate directory.

The OpenVMS builds need OpenVMS specific scripts and files to assist 
with the build procedure.  I generally put them in a [.vms] directory
and could keep all the OpenVMS specific modules there.

Regards,
-John