Re: [bug #41758] VMS Make incorrectly reports archives support present.

[h.becker]

On 06/02/2014 06:22 AM, John E. Malmberg wrote:
> On 5/31/2014 7:21 AM, h.becker wrote:
>> On 05/15/2014 05:51 AM, John Malmberg wrote:
>>> Follow-up Comment #4, bug #41758 (project make):

> This fixes 8 failing tests in the features/archives test.  Wildcard
> access now works correctly.  In addition the vpath3 test that was
> failing before now works correctly.  It needs to be modified to expect
> the result in VMS syntax.

OK, I'have a look at the archives tests.

>> However, the patch doesn't work if I dare to specify a module name
>> different from the file name. That worked with the unpatched version.
> 
> I need to look at that to see how it could have worked, since GNU Make
> is what is assuming that the module name is the same as the filename,
> and I do not see a syntax to tell it otherwise.

With "worked" I meant it didn't crash and it ran a library/replace
command. It didn't work in the sense that GNU make would know which
library module to look up and to compare with. To do so, I think one
would need to read the object module header. I don't think we should
teach GNU make to do that. The best one can do is to run analyze/object,
like
$ pipe anal/obj/mhd z |search sys$pipe "module name:"
        module name: "lower"
And yes, that works on I64 too, with a similar result:
$ pipe anal/obj/mhd z |search sys$pipe "module name:"
    Module name:                                "lower"

> The mhddef structure, which has the mhd$l_dattim member is sufficient.
> If there is more data, the lbr$_set_module is supposed to truncate the
> data to the size given and return a status of LBR-W-HDRTRUNC which is
> 2525184.  I can not find that value in any header file.

I didn't check whether lbr$_hdrtrunc is declared somewhere. Librarian,
aka LBR is BLiss, lbr$_hdrtrunc is declared external and resolved at
link time from lbrshr.exe. You can use globalvalue, which is a VAXC
feature - off the top of my head I don't how to do this in DECC, but
there is something, at least a #pragma extern_model:
$ cre z.c
globalvalue lbr$_hdrtrunc;
f() {printf("%%x%08x\n", lbr$_hdrtrunc);}
 Exit
$ cc/stand=vaxc z
$ link z
$ r z
%x00268800
$

> Diagnosing this also exposed a bug in mhddef.h.  The definition for
> mhd$l_datim is wrong.  It has it as a 32 bit longword instead of a 64
> bit structure or array.

Yes, the type is wrong, it is int and then there is a 4 byte filler: not
nice, but that's how it is (smells like Bliss32).

>> The test for imagelib seems to work on VAX only: I only see a UNIVERSAL
>> option and not a SYMBOL_VECTOR option.
> 
> I currently can only run the Perl test script on the Alpha system.  The
> symbol_vectors are not needed to test creating the library.

OK, I see what you mean. Yes, they aren't needed in the sense that
link/share flags the result as a "shareable image". So the tests create
a shareable without any symbol. It seems that librarian is not checking
whether the image has symbols or not. However, the whole purpose of a
shareable image library is to have the global symbol table in the
library. As I said before, it's a linker input file and opening one
library to get all these symbols is very convenient - not only for the
linker. Anyway, at least for now such shareables seem good enough for
the tests.