Gnu cmp doesn't work with Alpha object files

[Douglas Rupp]

This is the precompiled cmp 2.8.7a for Alpha/VMS. If I force the .objects to a fixed record format instead of variable length, it works. Please fix.

These two files are identical, I just copied one to the other for this test:

$ cmpnew sem_ch4.o sem_ch4.o1
$ cmpnew --ignore-initial=64 sem_ch4.o
$ cmpnew --ignore-initial=128 sem_ch4.o sem_ch4.o1
sem_ch4.o sem_ch4.o1 differ: char 39377, line 1

[John Gillings]

Douglas,

Perhaps you've misunderstood the nature of this forum. Most of the people who read and respond to questions are NOT HP engineers, so your request to "please fix" is most unlikely to get anywhere. You will need to log a support case with HP customer support to get any reasonable chance of something being fixed.

Is this an OpenVMS question/issue? What are the file characteristics of the input files? Have you tried dumping them at the point they're claimed to be different to see what's there?

Is Gnu cmp supposed to be able to compare binary files? If it's Gnu, doesn't that mean it's maintained by the open source community?

[Douglas Rupp]

I was advised by HP Engineering that the maintainer of the VMS version of this utility reads this forum, and to post the question here.

[Steven Schweda]

> Please fix.

Please send money.

> This is the precompiled cmp 2.8.7a for
> Alpha/VMS.

_the_ ???

Which you found where? I doubt that there's
only one "cmp" out there.

You might try adding some VMS-specific stuff
to the open() in [.src]cmp.c. For example:

ALP $ gdiff -u src/cmp.c_orig src/cmp.c
--- src/cmp.c_orig 2004-04-12 02:44:35 -0500
+++ src/cmp.c 2009-12-02 00:19:39 -0600
@@ -38,6 +38,12 @@
#include
#include

+#ifdef __VMS
+# define OPEN_ARG , "ctx = stm"
+#else /* def __VMS */
+# define OPEN_ARG
+#endif /* def __VMS [else] */
+
#if defined LC_MESSAGES && ENABLE_NLS
# define hard_locale_LC_MESSAGES hard_locale (LC_MESSAGES)
#else
@@ -286,7 +292,7 @@

file_desc[f1] = (strcmp (file[f1], "-") == 0
? STDIN_FILENO
- : open (file[f1], O_RDONLY, 0));
+ : open (file[f1], O_RDONLY, 0 OPEN_ARG));
if (file_desc[f1] < 0 || fstat (file_desc[f1], stat_buf + f1) != 0)
{
if (file_desc[f1] < 0 && comparison_type == type_status)


I don't know how much trouble this would
cause in other situations, but it may help
in this one.

alp $ copy modpro.OBJ x1.obj
alp $ copy modpro.OBJ x2.obj
alp $ gcmp --ignore-initial=128 x1.obj x2.obj
x1.obj x2.obj differ: char 39409, line 1
alp $ gcmpX --ignore-initial=128 x1.obj x2.obj
alp $

[Hoff]

>I was advised by HP Engineering that the maintainer of the VMS version of this utility reads this forum, and to post the question here.

Interesting. That would appear to be be a change from longstanding past practice around the forums and around bug-reporting, if that's the case.

I'd suggest duplicating this report into the porting conference over on DECUServe; that's where the majority of the GNV discussions currently reside, and where the GNV updates and workarounds tend to get created.

If the HP maintainer(s) of this stuff _is_ monitoring this stuff? Welcome! Post up a reply or two. And please get a distributed version control system up and running, or please get the current bits moved out to SourceForge rather than the internal storage apparently in use. And with that access, we can help you with these issues.

[Steven Schweda]

> [...] GNV [...]

From the "a" (and the "7") in "2.8.7a", I
suspect that he's using my stuff rather than
the GNV stuff, but my psychic powers are too
weak to give me much confidence in that
suspicion.

[Douglas Rupp]

All respects to GNV, but I have my own ports of all Gnu utilities, except diffutils, for which I'm using Steven Schweda's port.

[Hoff]

What is your goal?

It's clear that you know how to submit patches into the GNU codebase.

And certainly many of us are frustrated around the lack of access into the GNV stuff, and the way that the GNV code has been fork-ported from the GNU codebase. Providing a DVCS or SourceForge home for the code might not work, but what we have definitely doesn't work. (The cmp tool provided within GNV V2.1-2 reports itself as 2.7 Rev 1.5; nearly eight years back.)

(That your organization doesn't have a more direct path into HP is interesting in its own regard. But I digress.)

And FWIW, the usual approach on OpenVMS involves the ANALYZE /OBJECT mechanisms; I've not seen much use of cmp or DIFFERENCE against object files on OpenVMS. It's very likely that there's an object module dump tool around, too. (There are ports of xxd around, too.) But I'd guess you're aware of this.

And possibly related to this? The C RTL handling of binary data has been brought up before, and recently too:

http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1385811

[Craig A Berry]

If the goal is just to find out whether the files are identical, wouldn't checksum do the trick?

[Douglas Rupp]

Checksum might work, but I'm constrained by the Makefile.

[Douglas Rupp]

My overall goal is development of the complete Gcc toolchain for IVMS, and to do what I have to do to keep AVMS running well. I just don't have time or motivation to keep the Gnu tools up to date or to attempt to merge in my patches to FSF (a time consuming job). Send money. :-)

Cmp is used to compare objects built during the Gcc bootstrap, and has to skip over the MHD since it contains a timestamp. It used to be the MHD was very predictably sized for Gcc bootstrap objects. That's no long the case, so this latent problem appeared.

[H.Becker]

Checksum/object is only available for Elf/I64 object files: it excludes data like time stamps. It was a piece of Schwarzwaelderkirsch (how do I get umlauts into this entry?) after having checksum/image.

It shouldn't be so difficult to write such a tool: the Alpha object language is documented. But, you need it today, right?

[Douglas Rupp]

The suggestion to modify cmp open() with ctx=stm seems to work. I'll test it in production tonight.

Checksum for alpha does seem useful in general though.

[Steven Schweda]

> [...] ctx=stm seems to work. [...]

New (2.8.7b) kits should be available at:

http://antinode.info/dec/sw/diffutils.html

Included are this "cmp" change, and a
somewhat sneaky scheme to re-jigger the
argument list for fwrite() in the generic
code, so that a difference line in redirected
output (PIPE, DEFINE SYS$OUTPUT) will
comprise one N-byte record instead of N
1-byte records. (Previously, redirected
"diff" output was approximately useless.)

[Craig A Berry]

Steven said:

> (Previously, redirected
> "diff" output was approximately useless.)

Unless you use the home-grown redirection patch I sent you on 27-MAR-2009 and reattach here. With that the file is opened in C rather than DCL, which gives the user a much better chance of getting stream-oriented behavior. You also don't have to put "pipe" in front of things in order to do redirection.

Not that there's anything wrong with your approach either.

[Douglas Rupp]

FYI I put the in ctx=stm patch when you first suggested it, and it's all working again. Thanks.