GNV and CRTL

[Martin Vorlaender]

While building GNV from scratch I stumbled upon a CRTL behavior that I can't understand.

Environment: OpenVMS I64 V8.3-1H1 + VMS831H1I_UPDATE V8.0, HP C V7.3-019.

After fiddling a bit with the GNV sources, I took a GNU diff against the sourceforge source files and started over. To keep the SF source tree clean, I defined a GNV_ROOT consisting of GNV_SPECIFIC (my build directory) and GNV_COMMON (the SF source tree), and duplicated GNV_COMMON's directory structure in GNV_SPECIFIC. Then I SET DEFAULT GNV_ROOT:[000000], SET PROCESS/PARSE=EXTENDED/CASE=SENSITIVE, and called GNU patch with my diff file to carry over the changes to the new directory structure. Everything's fine for files like crtlsup/makefile.com or build/FEATURES.COM, but for file/file-4.09/src/compress.c patch says it can't find the input file. I traced this to a failing stat call (PCH\intuit_diff_type\%LINE 9402, errno=2 = ENOENT - No such file or directory). After some experimentation I found that to support unix paths that contain directory names with dots I have to define DECC$EFS_CHARSET. But the compress.c patch still fails under that...

Any other ideas why stat can't find this file?

TIA
Martin

[Martin Vorlaender]

Another data point: when I SET DEFAULT GNV_ROOT:[file.file-4^.09.src], and call GNU patch there (stripping 4 path elements), it works!

I don't get it...

[Craig A Berry]

I don't think the process settings for case handling and extended parsing have a one-to-one correspondence to what the CRTL does. For example, if case matters, you'll likely need DECC$EFS_CASE_PRESERVE and/or DECC$ARGV_PARSE_STYLE. In your problem example, though, it looks like it's all lower case.

Do check, since you have case sensitivity turned on, that the actual file and directory names on disk are the same as specified in the patch, e.g., that you have src.DIR;1, not SRC.DIR;1.

You might check whether you have the logical name "file" defined or try defining DECC$UNIX_PATH_BEFORE_LOGNAME. Make sure you do NOT have DECC$EFS_NO_DOTS_IN_DIRNAME defined.

I actually would have expected DECC$EFS_CHARSET to be enough in this example. Since it isn't, I would try a big hammer like:

$ define DECC$UNIX_LEVEL 30

and see what happens. You could also edit the patch to insert caret escapes, so

file/file-4.09/src/compress.c

becomes

file/file-4^.09/src/compress.c

which really shouldn't be necessary but might work.

Navigating to the subdirectory as you have done is a good one-off solution for one file, but wouldn't help if the patch had numerous files from several directories, so I hope we get to the bottom of this.

[Hoff]

IIRC, there was a particular link command that was used for parts of gnv; that included a lib$initialize psect module into the image that seeks to establish the DECC$ hackery correctly, IIRC.

[H.Becker]

What Hoff is refering to is crtlsup/src/vms_crtl_init.c

From what I read, you want to have/use GNV diff and patch. Patch seems to be missing in GNV, and your versions of these GNU tools for VMS seem to miss the necessary initialization with the DECC$ features. The above module should help or point you into the right direction..

[Craig A Berry]

vms_crtl_init.c is visible here:

http://gnv.cvs.sourceforge.net/viewvc/gnv/gnv213/crtlsup/src/vms_crtl_init.c?revision=1.1.1.1&view=markup

It looks like there is a version of GNU patch in the latest GNV:

http://gnv.cvs.sourceforge.net/viewvc/gnv/gnv213/patch/

but there have been various ports kicking around so I don't know if that's the one Martin is using.

[Martin Vorlaender]

Craig, Hoff, Hartmut,

thanks for the confirmation that it should have worked ;-) In detail:

I had carefully looked after the case of directory names (having been bit by that several times in this project). So yes, the whole path's case is exactly as it appears to patch:

$ dir [.gnv213.file.file-4^.09.src]compress.c

Directory DISK$BUILD:[build.gnv213.file.file-4^.09.src]

compress.c;1

Total of 1 file.

(BTW: GNV_SPECIFIC is defined as 'f$trnlnm("DISK$BUILD")'[build.gnv213.] )


I also fell into the logical name trap (though with MANPATH defined by CDE, and the man kit containing a manpath.OBJ file). But no, in this case "file" is not defined as a logical.

Re: DECC$UNIX_LEVEL : In my despair to get it to work (without testing any one of the dozens of feature logicals) I indeed set that logical to 30 once - no change.

Re: Inserting a caret into the Unix path : I tried that, though not with this patch, but in my general experiments with stat (see attached).

Re: Using vms_crtl_init / GNV's patch : I'm in the process of building the GNV environment from scratch, so no GNV utilities, please (except where the build process calls them). I have no idea where my gpatch.exe came from - it gets copied from system to system :-) Most probably it's the Freeware CD version. To trace the error, I fetched the sources from Freeware #5 and compiled it /DEBUG. So, no decc$feature_set here. BUT: the GNV environment contains FEATURES.COM which I called when setting it up. This defines a whole slew of DECC$* feature logicals. Should have the same effect, shouldn't it?

http://gnv.cvs.sourceforge.net/viewvc/gnv/gnv213/build/FEATURES.COM?revision=1.1.1.1&view=markup

(plus, of course, my definition of DECC$EFS_CHARSET).

Thanks,

Martin

[Craig A Berry]

I guess the next thing to do would be to make a tiny C program that does only a stat and see if you can reproduce the ENOENT that way. If so, then run it under SET WATCH FILE and see what it's actually looking for and can't find.

[Hoff]

This whole area of C has been a moving target, particularly around the logical name morass. Old C code can variously need tweaks here, and (when this arises) usually with the logical name settings. I'd not assume that old code works.

You'll need to decode the FEATURES.COM settings for your environment; that list of logical names is incomplete.

Don't turn on case sensitivity unless you absolutely need that. That switch will find filename and filename casing assumptions all over the place.

GNV has problems with mixed environments; mixing VMS file specifications and Unix path syntax is problematic. I'd suggest using (only) Unix syntax, as that path seems to be the most reliable.

Utility doesn't come from simplicity or surface aesthetics. Utility comes from forging complexity into something you can comfortably wield.

The GNV initialization code stuff establishes an lib$initialize initialization psect that sets the defaults for the executable; you can recreate this code yourself easily, and establish the defaults in a somewhat modular fashion. (This is the workaround for most of the DECC$* logical name morass.)

There are diff, patch and xxd tools in the OpenVMS vim kit over at Polarhome, if that's of interest.

I'd probably get (most of) the sourceforge svn out of the picture and run the repository with git; git-svn or a git svn clone command (if you're departing from svn) can help with that.

http://www.kernel.org/pub/software/scm/git/docs/git-svn.html

git svn clone http://PROJECT.svn.sourceforge.net/svnroot/PROJECT PROJECT.git

There are various issues with the default GNV set-up; have a look at the environment over at DECUServe for some of the fixes and updates that can be required.

And following the same vein, the DECUServe PORTING_TO_VMS notes conference has extensive information on C portability and the DECC$* settings.

I'd hope that the GNV project will decide to start using Sourceforge as something more than a file server and to engage the community, too; it'll be interesting to learn if this is a future during that upcoming GNV session.

It's often easier to fix the file formats (switching to stream LF) and migrate the VMS files to a platform with tools for the necessary work, then haul the stuff back to VMS to build it.

Build the reproducer, too. Narrow this stuff down.

I've posted some of my adventures with GNV. Here's one:
http://labs.hoffmanlabs.com/node/1481

Here are some of the topics associated with the DECC$* logical name settings:
http://labs.hoffmanlabs.com/node/1513
http://labs.hoffmanlabs.com/node/1515

"Utility doesn't come from simplicity or surface aesthetics. Utility comes from forging complexity into something you can comfortably wield." Unfortunately and problematically, both GNV and the C Unix compatibility environment and the current code-drop use model over at Sourceforge are presently al; rather unwieldy.

[Craig A Berry · Accepted solution]

Martin, just as a reminder that what goes around comes around, note the following in src/vms/vmsutil.c of the GNU patch distro on the Freeware CD v5.0:

* Stolen from the VMSperl source by Martin Vorlaender
* Um, that's actually GPB'd (GNU Public Borrowed) under the terms of the
* GNU Public License.

And a few lines further down:

*
* Wrapper routines added by Craig Berry based in part on code by Charles
* Lane.
*

So what's happening is our fault :-). As Hoff said, don't assume old code will work unmodified, even (especially?) if it's your own!

More specifically, there is a my_stat() wrapper around stat() that calls a home-grown converter routine to convert a filespec in Unix syntax to VMS syntax. The converter routine contains the following line in the part that handles the directory portion of the path:

else *(cp1++) = '_'; /* fix up syntax - '.' in name not allowed */

So we're explicitly defeating any attempt to make a dot in a directory name visible to the filesystem by converting it to an underscore. Remember, the target 10 years ago was VMS 6.x and early 7.x. There was limited or no capability in the CRTL to accept Unix-style pathnames, convert between Unix and VMS syntax, etc. ODS-5 did not exist and a dot in a directory name was a hard syntax error with no features to work around that.

I think your best bet may be to start over with the GNU patch from the GNV kit (or even just the authoritative GNU sources).