2017-05-23 16:29:53 UTC
While running the CMake 3.8.1 bootstrap executable (CMake builds in two stages; bootstrap CMake.exe is the result of the first stage) it bailed out after performing about 253 (or there about) tests because it could not open channels to any more files. After some sessions through the debugger, I discovered what appears to be a bug in the OpenVMS CRTL on HPE OpenVMS Alpha V8.3. It appears that lstat() leaves behind an open channel when called with a path that is a directory specification (e.g. PRJ_ROOT:[cmake-3^.8^.1.Source]) where the device portion of the directory specification (i.e. PRJ_ROOT in the example above) is a logical name defined as concealed with a list of directory logicals which are also defined as concealed. Each call to lstat() with such a directory specification as its first argument succeeds (assuming that the underlying logical name translation values are valid) but leaves behind an open channel to the physical disk device to which the translated physical directory specification refers. I have the DEC AXPVMS VMS83A_ACRTL V10.0 patch installed. But, I am not certain if that is the latest available for HPE OpenVMS Alpha V8.3. I am also not sure if anyone at HPE or VSI is aware of this particular bug or whether or not any subsequent CRTL patch actually fixes it.
This particular bug was revealed because, in the canonical Open Source GNV build environment that John Malmberg, Bill Pedersen and myself (and perhaps others as well) use when porting Open Source projects has three different directories that are all grouped together behind one concealed logical name PRJ_ROOT. The three directory configuration is used because it makes it simpler to determine which files are artifacts of the build process and which source files require modification in order to build on OpenVMS because such files are located in separate physical directories in their corresponding relative paths within the original source tree of the Open Source project.