John Peacock wrote:
While doing nothing fancy ("-des"), I see the following (running the second time for clarity, since Perl itself is already built):
I built this kit without incident and passed all tests using Compaq C 6.4 on OVMS Alpha 7.2-1.
KES-JPEACOCK> mmk Autosplitting Perl library . . . %CREATE-I-EXISTS, [.LIB.AUTO] already exists @make_ext "Sys$Disk:[]miniperl.exe" "MMK"
Making attrs (dynamic)
Making B (dynamic)
%MMK-F-ERRUPD, error status %X1000000C occurred when updating target DYNEXT
That's an access violation. Did it get any farther the first time you ran it? It could be blowing up running the Makefile.PL or any number of other things. In any case, it looks like a nasty one and we'll want to try to identify the exact step in building the extension that encounters the problem.
That "@make_ext" line is wrong (miniperl is not at the root of the current disk).
Nor is it expected to be. You have to pass a device and directory spec to MCR to keep it from looking in sys$system, so we pass it sys$disk:[], which just means the current default directory on the current disk.
I was running from a rooted logical (my normal behavior), where the root was one level up from [perl].
Once I ran PERL_SETUP.COM and then "set def PERL_ROOT:[000000]" then the make continues.
Curious. It's possible this could be part of the problem, but it's also possible it got far enough before it failed that a subsequent run considered it already built.
Is it possible to do
$ @configure -"Dusevmsdebug" -"des" $ mmk/macro=__DEBUG__=1
I can't guarantee it would show us the smoking gun, but it might.
