in reply to Re: Perl 5.12.0 has been released! (exetype problem 64-bit)
in thread Perl 5.12.0 has been released!

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
  • Comment on Re^2: Perl 5.12.0 has been released! (exetype problem 64-bit)

Replies are listed 'Best First'.
Re^3: Perl 5.12.0 has been released! (exetype problem 64-bit)
by BrowserUk (Patriarch) on Apr 14, 2010 at 09:44 UTC

    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]

        No. It fails with just nmake also.

        I've been using nmake install directly, because if you do nmake, nmake test followed by nmake install, each subsequent pass spends ages re-checking all the /ext /cpan /cpanp etc. directories.

        Doing nmake install saves time, but has no affect on the problem. I don't use the installed builds anyway, so I just put them somewhere out of harms way.

        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]
      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]
        different versions of nmake.exe

        I can't quite see how the version of nmake would affect this. The problem is very definitely a Perl internal error in miniperl.exe.

        I use CCTYPE        = MSVC90FREE as seems to best fit the compiler I'm using.

        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]

In Section Perl News