[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OpenVMS first test run report summary

From: John E. Malmberg
Subject: Re: OpenVMS first test run report summary
Date: Wed, 26 Jul 2017 23:21:12 -0500
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]