Corion has asked for the wisdom of the Perl Monks concerning the following question:

I saw the MS VC7 compiler offered, downloaded it, posted the news, downloaded the necessary libraries, and tried to build Perl with it. I had to patch Makefile so that the build process for miniperl works:

This is the diff of my 5.9.1 Makefile, as downloaded from :

< DELAYLOAD = -DELAYLOAD:wsock32.dll -DELAYLOAD:shell32.dll delayi +mp.lib --- > #DELAYLOAD = -DELAYLOAD:wsock32.dll -DELAYLOAD:shell32.dll delayi +mp.lib > DELAYLOAD = 347c348,349 < LIBC = msvcrt.lib --- > #LIBC = msvcrt.lib > LIBC = libc.lib 356c358,359 < OPTIMIZE = -Od -MD -Zi -DDEBUGGING --- > #OPTIMIZE = -Od -MD -Zi -DDEBUGGING > OPTIMIZE = -Od -ML -Zi -DDEBUGGING 360c363,364 < OPTIMIZE = -MD -DNDEBUG --- > #OPTIMIZE = -MD -DNDEBUG > OPTIMIZE = -ML -DNDEBUG 396c400 < CFLAGS = -nologo -Gf -W3 $(INCLUDES) $(DEFINES) $(LOC +DEFS) \ --- > CFLAGS = -nologo -GF -W3 $(INCLUDES) $(DEFINES) $(LOC +DEFS) \ 569c573 < # We need this for miniperl build unless we override canned --- > # We need this for miniperl build unless we override canned 788c792 < "ccflags=-nologo -Gf -W3 $(OPTIMIZE:"=\") $(DEFINES) $ +(BUILDOPT)" \ --- > "ccflags=-nologo -GF -W3 $(OPTIMIZE:"=\") $(DEFINES) $ +(BUILDOPT)" \ 820c824 < perlglob$(o) setargv$(o) --- > perlglob$(o) $(SETARGV_OBJ)

Miniperl builds OK, but when I do nmake test, I get an access violation in the newly created perl.exe for some instruction at 0x77892373, which tried to read memory at 0x000000000f - so I did something wrong while slashing around in the Makefile. But what?

Update: Rephrased the last paragraph

Replies are listed 'Best First'.
Re: Building Perl with the free MSVC tools
by demerphq (Chancellor) on Apr 19, 2004 at 08:11 UTC

    Ok, to summarize our CB conversation. Linking to libc is all wrong. Forget that. The /Gf changes appear harmless. As for msvcrt7.lib I assume you are trying to statically link against that lib. Dont bother, dynamically link against it and you should be ok. Additional resources are available in the "full SDK" or in the .Net Framework which you will need installed from WU afaik.

    Can I just say how aboslutely PHENOMENAL this is for Win32 Perl and Perl in general. Once we can get Perl to build on Win32 with the new compiler clean then the need for PPM's disappears. The arguments about different perl versions being built on different compilers should effectively disappear. The lack of Win32 portability due to no developers ahving compilers disappears. This is absolutely amazing stuff.

    We need to begin a project to "enhance" the Perl packaging mechanisms to handle downloading and installing the C compiler on demand. And we need to do it IMO, FAST. Ill be working on this, I hope you'll help, and any other volunteers are very welcome.

    Update: I successfulyl built A recent bleadperl (patch 22609) with the new compiler, all tests were good. Unfortunately i have the normal VC7 on my system as well as the free one. This may mean it used resources from the normal kit that it wouldnt be able to find on your system. Ill double check this later.


      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi

      I'm willing to lend a hand, but I have no experience with C compilers. Still, if there is anything you want me to do, try or test, I'm all yours.


      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

      Three Cheers for demerphq and Corion.

      As CountZero said, I'm all up for aiding in any tests however I can, though I am not very familiar or adept in making use of C compilers.

      Just Another Perl Alchemist
Re: Building Perl with the free MSVC tools
by CountZero (Bishop) on Apr 19, 2004 at 05:43 UTC
    I downloaded the compiler as well, but I'm not planning to do something as ambitious as compiling Perl.

    As long as I can compile the odd CPAN module, I will be happy. Do you know which --if any-- libraries I need to download for that?


    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

      I'm recompiling Perl because I believe strongly in compiling XS modules with the same compiler I compiled my Perl with - and the current Perl binaries were compiled with VC6 while I'm using VC7, a discrepancy that will most likely be trouble, or so I imagine.

      On the other hand, I haven't got Perl to compile yet, so I'm still stuck on VC6 myself :-)

Re: Building Perl with the free MSVC tools
by cyocum (Curate) on Apr 19, 2004 at 12:12 UTC

    This might be a dumb question but I downloaded the complier but I cannot find the "nmake" tool. I guess it does not come with the toolkit. Does anyone know where I could find it?

    Update: Many thanks to Corion for giving me the link to the nmake tool: here

Re: Building Perl with the free MSVC tools
by bmann (Priest) on Apr 19, 2004 at 23:18 UTC
    I finished building it earlier this afternoon. The key is that the MS .NET SDK insists on installing some files onto the system drive, even if you change the default installation drive.

    It took longer to satisfy nmake than it did to build! I took a few quick notes as I installed. Here's a quick recipe:

    1. Install MSVC free compiler
    2. Install the Platform SDK from:
    3. Download and install .NET SDK in order to satisfy msvcrt.lib requirement.

      Note: The .NET SDK installs files into two directories: one is user configurable and one isn't. I used "D:\Program Files\Microsoft Visual Studio .NET 2003", but the installer installed "lib" and "inc" into "C:\Program Files\Microsoft Visual Studio .NET 2003"

    4. Edit win32/Makefile - (patch inside the readmore)

    5. Fire up command prompt using Platform SDK shortcut
    6. run vcvars32.bat from compiler installation
    7. set LIB=%LIB%;C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib (In order to satisfy msvcrt req.)
    8. path=%PATH%;PATH_TO_SDK\Bin\Win64 (at the END of existing path, required for resource converter)
    9. unpack perl source and cd PATH_TO_UNPACKED_PERL\win32
    10. nmake
    11. nmake test # all tests passed - except skipped tests, of course
    12. nmake install

    Fresh, steamin' hot perl 5.9.1, ready to enjoy!

    I'll try to replicate the build with bleadperl over the next couple of days and post any fixes or corrections.

    Update: corrected LIB path (added Vc7\lib to LIB, see #7 above)

      At we have been building Perl 5.8.x for some time now with VS.NET 2002 (that links against msvcr70.lib and uses the msvcr70.dll that comes with .NET 1.0/1.0a)

      We have a guide for building Perl under win32 with VC++...
      (it is a very simple task)

      Iím not exactly sure what the problem here is, but to clarify a point...

      MSVCRT.dll is the Microsoft C Runtime Library.
      If you use MS VC++, your programs will only link and run with specific versions of this file; managed code or not.
      (the version of MSVCRxx used by the compiler cannot be changed or specified by the user)

      VS98 links only against msvcrt.lib (or maybe even an earlier version)
      VS.NET 2002 links only against msvcr70.lib
      VS.NET 2003 links only against msvcr71.lib

      I would assume that the free MS VC++ 2003 toolkit would only link against MSVCR71.lib

      msvcr70.dll is part of .NET 1.0(a)
      msvcr71.dll is part of .NET 1.1

      Please excuse me if I missed a point, it just seemed to me that there was a difficulty with building Perl under win32 with VC++ above 6.0 in this thread. If someone could clarify, I would be grateful.
        Please excuse me if I missed a point, it just seemed to me that there was a difficulty with building Perl under win32 with VC++ above 6.0 in this thread. If someone could clarify, I would be grateful.
        The point you missed is that none of this was done with any version of Visual Studio, which would make it much simpler.

        MS is offering an undocumented and incomplete toolkit for free. No crt library is included - for that you need to download the .NET SDK. In order to build perl with this freely available compiler there are a couple of other requirements that still need to be met after getting msvcrt.lib. My post details a working method - there may be better solutions.

        Interesting point about msvcrt70(1).dll. Only problem is, just msvcrt.lib (not 70 or 71) is included with the .Net download. Perl's Makefile specifies msvcrt.dll, does that mean it is targeted to VC 6?

Re: Building Perl with the free MSVC tools
by shay (Beadle) on Sep 01, 2004 at 12:22 UTC
    Some notes on how to build Perl with the free toolkit have recently been added to the README.win32 file (aka perlwin32 manpage) that comes with Perl. These notes are in the current development stream, and will hopefully be in the next release of Perl (5.8.6).

    For those who can't wait, here's what the new notes say:

    Microsoft Visual C++ Toolkit 2003

    This free toolkit contains the same compiler and linker that ship with Visual Studio .NET 2003 Professional, but doesn't contain everything necessary to build Perl.

    You will also need to download the "Platform SDK" (the "Core SDK" and "MDAC SDK" components are required) for header files, libraries and rc.exe, and ".NET Framework SDK" for more libraries and nmake.exe. Note that the latter (which also includes the free compiler and linker) requires the ".NET Framework Redistributable" to be installed first. This can be downloaded and installed separately, but is included in the "Visual C++ Toolkit 2003" anyway.

    These packages can all be downloaded by searching in the Download Center at

    Note that the "Platform SDK February 2003" download requires Internet Explorer 5.0 to function. Alternatively, the very latest version at the time of writing (called "Windows XP Service Pack 2 Platform SDK RC2") is now available as an ISO-9660 CD image file and does not require IE5 to be downloaded but will only work on Windows XP.

    According to the download pages the Toolkit and the .NET Framework SDK are only supported on Windows 2000/XP/2003, so trying to use these tools on Windows 95/98/ME and even Windows NT probably won't work.

    Install the Toolkit first, then the Platform SDK, then the .NET Framework SDK. Setup your environment as follows (assuming default installation locations were chosen):

    SET PATH=%SystemRoot%\system32;%SystemRoot%;C:\Program Files\Micro +soft Visual C++ Toolkit 2003\bin;C:\Program Files\Microsoft SDK\Bin;C +:\Program Files\Microsoft.NET\SDK\v1.1\Bin SET INCLUDE=C:\Program Files\Microsoft Visual C++ Toolkit 2003\inc +lude;C:\Program Files\Microsoft SDK\include;C:\Program Files\Microsof +t Visual Studio .NET 2003\Vc7\include SET LIB=C:\Program Files\Microsoft Visual C++ Toolkit 2003\lib;C:\ +Program Files\Microsoft SDK\lib;C:\Program Files\Microsoft Visual Stu +dio .NET 2003\Vc7\lib

    Several required files will still be missing:

    • cvtres.exe is required by link.exe when using a .res file. It is actually installed by the .NET Framework SDK, but into a location such as the following:


      Copy it from there to C:\Program Files\Microsoft SDK\Bin

    • lib.exe is normally used to build libraries, but link.exe with the /lib option also works, so create a batch file called lib.bat in C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin containing:

      @echo off link /lib %*

      This will work as long as "lib.exe" is invoked simply as "lib" (which it is during the Perl build process).

    • setargv.obj is required to build perlglob.exe (and perl.exe if the USE_SETARGV option is enabled). The Platform SDK supplies this object file in source form in C:\Program Files\Microsoft SDK\src\crt. Copy setargv.c, cruntime.h and internal.h from there to some temporary location and build setargv.obj using

      cl.exe /c /I. /D_CRTBLD setargv.c

      Then copy setargv.obj to C:\Program Files\Microsoft SDK\lib

    Perl should now build using the win32/Makefile. You will need to edit that file to comment-out CCTYPE = MSVC60 (since that enables delay-loading of the Winsock DLL which the free toolkit does not support) and to set CCHOME, CCINCDIR and CCLIBDIR as per the environment setup above.

    Note that Perl should be unpacked into a directory path that does not contain any spaces otherwise MakeMaker will experience some problems. There is no harm in having the MS toolkit and other packages installed into their default C:\Program Files locations.

    Also note that if you are going to use the free toolkit to build C extension modules then you should use the same compiler as was used to build Perl. ActivePerl is currently built using MSVC6, so its perl.exe is linked against MSVC6's msvcrt.lib and depends on the OS's msvcrt.dll. The new toolkit (MSVC7) has an msvcrt.lib which produces binaries depending on msvcrt71.dll. So if you use the free toolkit to build modules for ActivePerl then you'll end up loading two different C runtime DLL's and you will run into trouble if any CRT resources (e.g. file decriptors) get passed between them. If you're going to build modules with the free toolkit then you're best off rebuilding Perl with it yourself too.

    - Steve