bug-make
[Top][All Lists]
Advanced

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

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


From: h.becker
Subject: Re: [bug #41758] VMS Make incorrectly reports archives support present.
Date: Fri, 20 Jun 2014 15:53:44 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130519 Icedove/17.0.5

On 06/14/2014 07:44 PM, John E. Malmberg wrote:
>> In arscan.c, I suggest to use LBR$_HDRTRUNC instead of LIB_W_HDRTRUNC. A
>> "globalvalue unsigned int LBR$_HDRTRUNC;" replaces the "#define
>> LIB_W_HDRTRUNC 2525184" and the check changes to "if ((status !=
>> LBR$_HDRTRUNC) && ..."
>>
>> Globalvalue is the right storage class for this declaration as per
>> definition LBR$_HDRTRUNC can change any time.   With resolving it at link
>> time and doing a fixup at activation time the code will get the correct
>> value even if it is changed. I agree, I don't expect it to be changed,
>> but having own #defines for VMS defined values looks wrong to me. And as
>> far as I can see there are no LBR$_<code> return codes defined in any of
>> the LBR header files and it seems unlikely that this will be changed
>> (sooner or later or at all) by VMS engineering.
> 
> VMS convention has always been to use these as compile time constants
> which means that once they are set, they are never changed for backwards
> compatibility.

Whatever VMS conventions apply. LBR$_HDRTRUNC is defined (as a global
value) in the shareable image, that gives the wanted compatibility. The
value can change without affecting the compatibility. Whether someone
will change it, explicitly or implicitly, is another question. The
correct value is always available at run time, re-defining it at compile
time looks wrong. If LBR$_HDRTRUNC should be defined at compile time one
would expect its value to be in any .TLB, .MLB or bliss library. As far
as I can see, LBR$_HDRTRUNC isn't defined in any of them.

> 
> globalvalue is only visible if VAXC compatibility is active, and turning
> on stricter ANSI compliance in the compiler turns it off.  Turning on
> the stricter ANSI compliance finds bugs that VAX C compatibility
> ignores, so that is something that is desired.
> 
> While there is a ANSI compatible VMS extension to allow the equivalent
> of a globalvalue, it is a bit ugly to use.
> 
> And the compiler best optimizes as a constant, not as a global value
> that is not known until run time.
> 
> So with all that considered, just setting a constant missing from the
> header files seems the best solution.

globalvalue is visible in /STANDARD=VAXC and /STANDARD=RELAXED which is
the default. Is that what you refer to as 'ANSI compatible VMS
extension'? The default gives at least fair diagnostics for VAXC
problems. At the moment gnu make is compiled either without a standard
switch or the /STANDARD=RELAXED, but with
/WARNING=(DISABLE=QUESTCOMPARE). In stricter modes you can use something
like

#include <stdio.h>
extern unsigned int LBR$_HDRTRUNC;
int main (void) {
        printf ("LBR$_HDRTRUNC: %%x%08x\n", &LBR$_HDRTRUNC);
}

and you may want to add at least DOLLARID to the disabled warning messages.

And, at activation time, the shareable image with the fixups is read
anyway and applying one more fixup isn't a big deal - on any platform.
Agreed, a couple of instructions are generated to deal with a value not
known at compile time.

Again, this isn't a single constant missing in a header file. None of
these constants is defined in any header file.

> 
>> In tests/scripts/vms/library I suggest to remove the "universal" option
>> from the test script. For image libraries, librarian seems to be happy
>> with an image which is flagged as a shareable image no matter whether it
>> has a global symbol table or not. So there is no need to have one on VAX
>> but none on Alpha/I64; in other words on all VMS platforms I suggest to
>> either use a global symbol table or to use none.
> 
> I will look at doing that in a future patch.  It appears that the
> UNIVERSAL qualifier is ignored by non-VAX, so is not causing a problem.

Like "%LINK-I-OPTIGNALPHA, UNIVERSAL option ignored; not allowed for AXP
images" but
%ILINK-F-OPTSYNERR, syntax error in options file ...
-ILINK-E-OPTLIN, options line in error
        'UNIVERSAL'=MAIN
I didn't try the tests on I64, but the -F should trigger something.



reply via email to

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