Re: Free MSVC tools + Activestate to compile CPAN Modules
by demerphq (Chancellor) on Aug 31, 2004 at 07:31 UTC
|
Cool great. BTW, a minor point or two, its better to set your paths by using the vcvars32.bat batch file, or to spawn a shell that is installed in the start menu that launches with it automatically. Also:
If you want to avoid pain, don't put spaces in the install paths of anything above. Manually specify every path into a usefully short high level name. Don't use the defaults!
Yes its possible to get everything working with spaces in the paths, but its much easier to avoid them in the first place. If you have problems with paths with spaces in them have a gander at junction to make a new directory that is an alias to the one with spaces in it. And then update your paths.
Returning to paths its well worth the time IMO to transer all of the paths normally loaded by vsvars32.bat or vcvars32.bat into your system enviornment. The easiest way to do this is to in an open shell
C:\>set > setenv.txt
c:\>vsvars32
c:\>set > vsenv.txt
c:\>diff setenv.txt vsenv.txt > diff.txt
and then use the diff.txt to C&P the missing values into your system enviornment. This way if any of perls or cpans build enviornment spawns any of the c tools regardless of how or when you will always have the correct enviornment available.
Additionally you can find a free version of nmake.exe here unpack it and put it in your path somewhere (or put where it is in your path, *shrug*).
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
| [reply] [d/l] |
|
its better to set your paths by using the vcvars32.bat
The set commands I listed above include the vcvars32.bat commands. But the vcvars32.bat does not set the environment for the SDK, only the Toolkit so it is not sufficienct by itself. You can save the set commands listed above as a batch file and run that *instead* of vcvars32.bat, or, as you point out, you can put these permanently in your enviornment (do as demerphq advices to make a diff, then, right click on my computer, select properties-advanced, select environment variables, find the PATH, LIB, and INCLUDE vars and set them with the output of the diff, or as I show above).
If you want to avoid pain, don't put spaces in the install paths
While I am sure you are right for most paths that have to do with perl, I do not believe that the spaces make any difference when they are meant (as the ones in the set commands above are) exclusively for use by windows. OTOH, the spaces bit me (and you helped me, thanks) when I tried to put the perl build (the one I unsuccessfully tried to build manually) in a directory with spaces. Your advice is probably safest as a general policy, but I really don't think it should or does make any difference for the compiler tools.
| [reply] |
|
but I really don't think it should or does make any difference for the compiler tools.
My worry is that it may cause problems for such things as Inline.pm or ExtUtils::MakeMaker or various other cpan packages that involve compiling (some packages will try to compile little C snippets to see if your C compiler is available). Not all of these packages are smart enough to handle the various cross platform issues that come up, especially not spaces in the install paths.
I _strongly_ recommend that you install as much as possible in paths with no spaces for this reason. For instance I usually install Visual Studio dotNet in E:\dotNet and not in the MS recommended ditrectories. Ive never had a problem as long as I did this. However every time i forget about this (when I build a new machine for instance) and I always end up getting bitten and having to junction or reinstall. So while im sure a lot of stuff will work fine, i think the safest plan, and the lowest stress is to avoid them. After all its always when you have 6 minutes to get something done that a CPAN install blows up and starts wining about not being able to find the compiler that is most definately there. :-)
OTOH, im not going to get too strung out about it, after all Ive already installed them in directories without spaces in their names so it wont be me getting bitten. :-p
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
| [reply] |
|
|
Re: Free MSVC tools + Activestate to compile CPAN Modules
by Corion (Patriarch) on Aug 31, 2004 at 06:54 UTC
|
As a small, Perl-only starter set for the Unix Utilities, I now avoid downloading and installing cygwin and use the Win32 Unix Utils as found on http://unxutils.sourceforge.net, as the three programs needed by Perl are only tar, gzip and wget for good measure. With these, the ugly errors of mismatched cygwin1.dlls are gone, and these three programs are easily put where the perl.exe binary resides too.
| [reply] |
|
Yes, good point about the cygwin dlls. Also, make sure that your windows Perl is in your path *before* cygwin, otherwise you might end up using cygwin's perl by default.
| [reply] |
Re: Free MSVC tools + Activestate to compile CPAN Modules
by strat (Canon) on Aug 31, 2004 at 06:49 UTC
|
If you compile modules, you might need the same version of the compiler perl was compiled (if you use the Activestate-binary, I think you need VisualC6 (which works fine for me). But I don't know if you can download it for free, or at least the build tools)
Well, with the free nmake you can compile a lot of cpan-modules, but for many you need the whole compiler suite (e.g. cl.exe and so on)
Best regards,
perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"
| [reply] |
|
If you compile modules, you might need the same version of the compiler perl was compiled (if you use the Activestate-binary, I think you need VisualC6
That kind of thinking is what prevented me from trying this in the first place. Do you have any proof that purchasing and using VC6 is any different from using the free VC Toolkit I mention above when compiling using the ActiveState build? (not a rhetorical question, I'd like to know). So far I have not found any modules that don't work with the free version.
Well, with the free nmake you can compile a lot of cpan-modules
Strictly speaking, that isn't true. You can *install* non-XS modules with just nmake.exe but you need a compiler to *compile* XS modules. Nmake.exe comes included in the free SDK mentioned above so there is no need to download it separately. But you're right that nmake.exe by itself is useful for installing non-XS modules for those who don't want to or can't download the the full compiler.
| [reply] |
|
Generally you do need to use the same compiler to build CPAN modules as was used to build Perl.
Upto version 6 of MSVC++ you can probably get away with using different versions: linking against msvcrt.lib always produced binaries depending on msvcrt.dll, which ships with the OS.
However, from version 7 onwards (and the free toolkit is version 7) linking against msvcrt.lib now produces binaries depending on msvcr71.dll (or whatever the latest version is).
ActivePerl is built using MSVC6, so if you build a module using the free tollkit then perl.exe will load msvcrt.dll and the module's DLL will load msvcr71.dll. If any CRT resources (e.g. file descriptors) are passed between the two then you'll have problems.
I recently discovered this with one of my CPAN modules (Win32-UTCFileTime-1.32). I was able to fix it (in 1.33) by falling back to an OS-level filehandle if the passing of the CRT file descriptor failed. However, another of my modules (Win32-SharedFileOpen) definitely does not work with ActivePerl if built using the free toolkit -- it does much more passing around of CRT resources and can't be fixed as easily. The solution is either to build it with MSVC6, or rebuild Perl using the same compiler as is being used to build the module.
Microsoft have a brief note about the perils of loading two different CRT DLL's at this URL (at the time of writing!):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_c_run.2d.time_libraries.asp
- Steve
| [reply] |
|
This is wrong. For a project I'm working on we compile an XS module using Cygwin's mingw32 compiler, we don't use the MakeMaker Makefile but a hand rolled one, but the generated .dll still loads fine with ActivePerl.
Admitedly Cygwin is not much help with CPAN modules, as MakeMaker will produce nmake formated Makefiles, but if a mingw32 .dll will link fine then any version of MSVC should work.
| [reply] |
Re: Free MSVC tools + Activestate to compile CPAN Modules
by Wassercrats (Initiate) on Aug 31, 2004 at 01:49 UTC
|
I informed you in CB yesterday that I'd done research into this and pointed you to my scratchpad (top part for now--will eventually be removed), where I still have a little information that might be helpful. I don't know if you had me on ignore, or if it didn't apply to you, but you didn't respond to me.
Incase anyone hasn't noticed, I occasionally try to help people here, and nobody has a good reason to /ignore me in CB. If you think you do, then post the reason, with adequate detail, to your home node to warn others about me. | [reply] |
|
| [reply] |
|
I'll have to use my mental powers to upvote you, since I don't have the ability to do it any other way.
| [reply] |
|
|
|
Re: Free MSVC tools + Activestate to compile CPAN Modules
by Courage (Parson) on Sep 01, 2004 at 05:27 UTC
|
| [reply] |
Re: Free MSVC tools + Activestate to compile CPAN Modules
by xdg (Monsignor) on Nov 17, 2007 at 19:17 UTC
|
If anyone is trying this with a recent version of the free MSVC tools, please see Problems with FREE MS VC++ tools -- particularly the update about needing a perl.exe.manifest file for MSVC 8.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply] [d/l] |
Re: Free MSVC tools + Activestate to compile CPAN Modules
by mpeppler (Vicar) on Sep 30, 2004 at 10:43 UTC
|
I just used this information to build PPDs for DBD::Sybase. These are now available with the other DBI binaries on http://ftp.esoftmatic.com/DBI/.
Michael
| [reply] |
|
Like shay said, those binaries will depend on MSVCR71.dll,
so it's only prudent to at least warn users (one way to warn).
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] |
|
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in. |