in reply to Building 64bit Perl for Windows

According to this article on microsoft.com you need to link against one of the bufferoverflow*.lib libraries if you get that error.

You can probably set that during Configure; (I've never build perl on win32, so maybe somebody else can give more hints).

update: I found that page by just pasting "error LNK2001: unresolved external symbol __security_check_cookie" into google - in my experience that usually turns up a solution with link errors.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Replies are listed 'Best First'.
Re^2: Building 64bit Perl for Windows
by puploki (Hermit) on Aug 10, 2005 at 17:40 UTC
    Thanks for that, I had Googled for pretty much the same but I thought I'd turned up nothing. I must be blind :)

    However, I've tried disabling the GS flag with... 

    set CL=/GS-

    [download]

    ... but that doesn't help. The command line it seems to be running is using "link" rather than "cl" though:

        link -nologo -nodefaultlib -debug -opt:ref,icf -ltcg  -libpath:"c:
+\perl\lib\CORE"  -machine:AMD64   oldnames.lib kernel32.lib user32.li
+b gdi32.lib winspool.lib  comdlg32.lib advapi32.lib shell32.lib ole32
+.lib oleaut32.lib  netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib
+  version.lib msvcrt.lib -out:..\perlglob.exe -subsystem:console  per
+lglob.obj setargv.obj
perlglob.obj : error LNK2001: unresolved external symbol __security_ch
+eck_cookie
..\perlglob.exe : fatal error LNK1120: 1 unresolved externals

    [download]

    Like I said, I'm waaay out of my depth here, so please bear with me :) It's odd that there's isn't an ActiveState 64bit Perl release yet - the architecture of these machines are all the same now, unlike the bad old days of IA64. In 12 months or so most OEM machines you buy will be 64bit Windows as well I bet...

[reply]
[d/l]
[select]
      No, that wouldn't help. You have to cut'n'paste the command you typed (presumably nmake) and everything that follows (up to and including the error) so others can understand what's going on.

      What you need to focus on is patching Makefile so that all the special flags amd64 requirs get added. Something like this (as far as I got before I without the libraries) 

      # PodMaster - UNLESS YOU INSTALL THEM (i don't have oldnames, but so w
+hat)
LIBBASEFILES    = $(LIBBASEFILES) odbc32.lib odbccp32.lib


# PodMaster
!IF "$(CCTYPE)" == "MSVC60"
OPTIMIZE    = $(OPTIMIZE) -Op
!ELSE
OPTIMIZE    = $(OPTIMIZE) -Wp64 -Op
!ENDIF

# PodMaster
!IF "$(PROCESSOR_ARCHITECTURE)" == "x86"
!IF "$(CPU)" == "AMD64"
WIN64            = define
PROCESSOR_ARCHITECTURE  = AMD64
!ENDIF
!ENDIF

#PodMaster
!IF "$(CPU)" == "AMD64"
LINK_FLAGS    = -nologo -nodefaultlib $(LINK_DBG) \
        -libpath:"$(INST_COREDIR)" \
        -machine:IX86
!ELSE
LINK_FLAGS    = -nologo -nodefaultlib $(LINK_DBG) \
        -libpath:"$(INST_COREDIR)" \
        -machine:$(PROCESSOR_ARCHITECTURE)
!ENDIF

      [download]
      Sorry its not in patch format, but you should be able to figure out where to inject these statements. From my notes apparently I used this article to help in sorting out this stuff, but like I said earlier, MS doesn't provide the libs for WinXPHome so I didn't get far.

      MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
      I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
      ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]
[d/l]
        Many thanks for your reply, it's very much appreciated.

        The command I'm typing is just "nmake" - no options or anything, or at least, that's what the documentation implies. I'm not using Visual Studio at all, just the SDK - maybe that's an issue?

[reply]

In Section Seekers of Perl Wisdom