At 11:27 AM 4/17/2001 +0200, Martin Vorlaender wrote:
>- The configuration test for long doubles gives
<snip>
> %CC-I-LONGDOUBLENYI, In this statement, type long double has the same
> representation as type double on this platform.
<snip>
> $ write sys$output $status
> %X10B90003
>
> As CONFIGURE.COM only tests for %X10B90001, it does detect the
> presence of long doubles, but fails to get the size. Not sure
> how to resolve this.
I don't have a way to test this, but something like this could work; let me
know if you get a chance to try it:
--- configure.com;-0 Sat Mar 3 13:53:20 2001
+++ configure.com Tue Apr 17 12:42:48 2001
@@ -3075,8 +3075,13 @@
$ ELSE
$ echo "You have long double."
$ echo4 "Checking to see how big your long doubles are..."
-$ GOSUB just_mcr_it
-$ longdblsize = tmp
+$ IF compile_status .EQ. %X10B90003 ! CC-I-LONGDOUBLENYI
+$ THEN ! long double same size as double
+$ longdblsize = doublesize
+$ ELSE
+$ GOSUB just_mcr_it
+$ longdblsize = tmp
+$ ENDIF
$ d_longdbl = "define"
$ echo "Your long doubles are ''longdblsize' bytes long."
$ ENDIF
[end of patch]
Or should we make long doubles undef in this case? It doesn't seem like
they'd offer any real advantage.
>- If you go with the DCL tables verb (instead of the foreign command),
> "MMK INSTALL" fails, because it wants to SET COMMAND the PERL.CLD
> file from PERL_ROOT:[000000] - which doesn't exist. I suppose
> SYS$DISK:[] would suffice here.
Hmm. Does this problem go away if you create the top-level directory before
the install?
>I didn't take notes on the modules' build, but if anyone is
>interested, I could publish my diffs.
Please do, preferably to the module authors as well as here. Thanks for the
report.
