in reply to Perl 5.12.0 has been released!

Anyone else getting this problem building 5.12 for 64-bit windows? 

Finished generating code
        if exist ..\perl.exe.manifest mt -nologo -manifest ..\perl.exe
+.ma
        copy ..\perl.exe ..\wperl.exe
        1 file(s) copied.
        ..\miniperl.exe -I..\lib bin\exetype.pl ..\wperl.exe WINDOWS
'x' outside of string in unpack at bin\exetype.pl line 39.
NMAKE : fatal error U1077: '..\miniperl.exe' : return code '0xff'
Stop.

[download]
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP an inspiration; A true Folk's Guy

Replies are listed 'Best First'.
Re^2: Perl 5.12.0 has been released! (exetype problem 64-bit)
by syphilis (Archbishop) on Apr 14, 2010 at 07:53 UTC
    Anyone else getting this problem building 5.12 for 64-bit windows?

    Builds fine for me straight out of the box with the (64-bit) Microsoft Platform SDK for Windows Server 2003 R2 compiler.
    I guess you would have had to remove the bufferoverflowU.lib from win32/Makefile ... or did you use makefile.mk ?

    Cheers,
    Rob
[reply]

      If you remember, I long ago aquired a copy of bufferoverflowU.lib and stuck it in my compiler lib directory. It satisfies the linker's need to find it, even though it is never called upon to supply any entrypoints.

      But I guess that the bufferoverflowU problem could be avoided by: 

      # The 64 bit Platform SDK compilers contain a runtime library that doe
+sn't
# include the buffer overrun verification code used by the /GS switch.
# Since the code links against libraries that are compiled with /GS, t
+his
# "security cookie verification" must be included via bufferoverlow.li
+b.
!IF "$(WIN64)" == "define" && ( "$(CCTYPE)" == "MSVC80" || "$(CCTYPE)"
+ == "MSVC80FREE" )
LIBBASEFILES    = $(LIBBASEFILES) bufferoverflowU.lib
!ENDIF

      [download]

      That said, it is intriguing that you are not having the same problem with exetype.pl. It is only a problem here when run under miniperl.exe... It was at this point it dawned on my that in order to be modifying wperl.exe, it had just copied a successfully built perl.exe.

      So, insteand of using $(MINIPERL) it should be possible to use $(PERLEXE) to work around the problem with miniperl. And it is and does. With that change, nmake install completes successfully. 

      $(PERLEXE): $(PERLDLL) $(CONFIGPM) $(PERLEXE_OBJ) $(PERLEXE_RES)
    $(LINK32) -subsystem:console -out:$@ -stack:0x1000000 $(LINK_FLAGS
+) \
        $(LIBFILES) $(PERLEXE_OBJ) $(SETARGV_OBJ) $(PERLIMPLIB) $(PERL
+EXE_RES)
    $(EMBED_EXE_MANI)
    copy $(PERLEXE) $(WPERLEXE)
#    $(MINIPERL) -I..\lib bin\exetype.pl $(WPERLEXE) WINDOWS
    $(PERLEXE) -I..\lib bin\exetype.pl $(WPERLEXE) WINDOWS

      [download]

      And while we're at it, the spurious -Wp64 is deprecated and will be remove warning could go: 

      !IF "$(WIN64)" == "define"
DEFINES        = $(DEFINES) -DWIN64 -DCONSERVATIVE
!IF "$(CCTYPE)" == "MSVC80" || "$(CCTYPE)" == "MSVC80FREE" 
OPTIMIZE    = $(OPTIMIZE) -Wp64 -fp:precise
!ELSE
OPTIMIZE    = $(OPTIMIZE) -fp:precise
!ENDIF
!ENDIF

      [download]

      Would those changes work on your 2003 setup?

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
        With that change, nmake install completes successfully.

        Was this an 'nmake install' issue ? I assumed it was happening during 'nmake' and didn't go beyond 'nmake test'.

        I'll take a look at the other stuff (and run 'nmake install' if need be) tomorrow .... bedtime over here :-)

        Cheers,
        Rob
[reply]
        it is intriguing that you are not having the same problem with exetype.pl

        Yes - 2 things come to mind. One is that we're possibly using different versions of nmake.exe (mine is "Version 7.00.8882"). The other is that we're probably specifying different values for "CCTYPE" in win32/Makefile. I've stuck with the default "MSVC60" - which seems to be working well enough, though seems a bit of an odd choice. (In that my compiler uses the msvcrt.dll runtime (afaik) it can also be argued that's a very sane choice.)

        In any case, I've just reset CCTYPE to MSVC80, and perl still builds ok for me. What setting for CCTYPE have you been using ?

        I still haven't got around to trying those amendments you posted ... and it's getting late again ... have to put that off until tomorrow.

        Cheers,
        Rob
[reply]

In Section Perl News