At 9:57 AM +1030 3/28/08, Jeremy Begg wrote:
>Hi,
>
>I've downloaded the Perl 5.10.0 tarball, unpacked it, and attempted to build
>it. My system is OpenVMS Alpha V8.3 with the HP C V7.3 compiler (the latest
>one).
>
>I ran CONFIGURE.COM with no parameters on the command line and it eventually
>failed with this error:
Thanks for the report.
> $ @configure
> .
> .
> .
> Choosing the C types to be used for Perl's internal types...
> (IV will be "long long", 8 bytes)
> (UV will be "unsigned long long", 8 bytes)
> (NV will be "double", 8 bytes)
Here's the first place something isn't right. You've asked for
maximal 64-bitness, which I think should give you long double for
NVs as well as long integers for the integer types. Even though
long doubles tend to be 80 bits or 128 bits, maximal 64-bitness
basically means "the biggest sizes available for everything."
> Checking whether your NVs can preserve your UVs...
> %RMS-E-EOF, end of file detected
> $
>
>It's probably relevant that I specified the following when asked about what
>data sizes to use:
>
> Try to use 64-bit integers, if available? [n] y
> Try to use maximal 64-bit support, if available? [n] y
>
>The only other questions to which I supplied non-default answers were:
>
> What is your e-mail address? [EMAIL PROTECTED] [EMAIL PROTECTED]
> Build a DEBUGGING version of Perl? [y] n
>
>I think the problem is that the "C" code used for the test in question is
>functionally incomplete. Here's the relevant bit of CONFIGURE.COM ...
>
> $ echo4 "Checking whether your NVs can preserve your UVs..."
> $ OS
> $ WS "#if defined(__DECC) || defined(__DECCXX)"
> $ WS "#include <stdlib.h>"
> $ WS "#endif"
> $ WS "#include <stdio.h>"
> $ WS "int main() {"
> $ WS " ''uvtype' k = (''uvtype')~0, l;"
> $ WS " ''nvtype' d;"
> $ WS " l = k;"
> $ WS " d = (''nvtype')l;"
> $ WS " l = (''uvtype')d;"
> $ WS " if (l == k)"
> $ WS " printf(""preserve\n"");"
> $ WS " exit(0);"
> $ WS "}"
> $ CS
> $ GOSUB compile
>
>You'll notice that it produces output ("preserve") if the value is preserved,
>and produces no output otherwise. But the COMPILE subroutine expects output
>to always be produced:
>Which leads me to two questions,
>
>1. Is my analysis correct, and would the fix be as simple as replacing
>
> if (l == k)
> printf("preserve\n");
> exit(0);"
>
> by
>
> if (l == k) {
> printf("preserve\n");
> }
> else {
> printf("corrupted\n");
> }
> exit(0);
>
> Or perhaps the better solution would be to fix the COMPILE routine to
> handle an empty output file, either by fixing the READ statement or
> simply appending a line of text (even an empty line) to the CONFIG
> file immediately after running try.exe. (The latter is probably the
> simpler approach, although less "correct".)
Your analysis is correct, and your code snippet would certainly do
the trick. I think it's reasonable for the COMPILE gosub to expect
some output, so I wouldn't recommend changing that.
It looks like the current unix Configure script, though, no longer
does this check and instead predicates d_nv_preserves_uv on
nv_preserves_uv_bits. If the number of bits preserved is greater
than or equal to the total number of bits in a UV, then the former is
defined. So I think I will make it imitate that behavior.
>2. Am I being naive in expecting this level of 64-bit support on VMS?
No. You should be able to get what you were looking for by configuring with:
$ @configure -"UDEBUGGING" -"Duse64bitint" -"Duselongdouble" -
_ -"[EMAIL PROTECTED]" -"de"
The only 64-bit thing you can't get right now is 64-bit pointers.
You could try getting it by adding /POINTER_SIZE=LONG to your
ccflags, but I suspect there would be a lot of code clean-up to do to
get this working.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
