I'm running Windows 7 Home Premium 64-bit. I need to install the perl
5.24 binary.
at http://www.activestate.com/activeperl/downloads I get two choices:
download activeperl 5.24.0 for windows (x86)
download activeperl 5.24.0 for windows (64-bit, x64)
Which of those two do I need?
Call me dense but I don't find my answer at How can I check whether my Perl installation is 32 or 64 bit?
whether-my-perl-installation-is-32-or-64-bit, although it does tell how to
display several version-related characteristics
perl -V:ivsize says
ivsize='8';
perl -V:archname says
archname='MSWin32-x86-multi-thread-64int';
perl -v says
This is perl 5, version 20, subversion 1 (v5.20.1) built for MSWin32-x86-multi-thread-64int
(with 1 registered patch, see perl -V for more detail)
Copyright 1987-2014, Larry Wall
Binary build 2000 [298557] provided by ActiveState
http://www.ActiveState.com
Built Oct 15 2014 22:10:49
Please help.
Phil
As your system is 64 bit. So I suggest you to install 64-bit, x64 one. You can install 32 bit also. 64 bit system support both 64 bit and 32 bit. But in case of 64 bit performance will be better.
As Arijit says, you should default to the 64-bit version as it will handle larger numerical values more efficiently and allows access to larger memory pools.
Exceptions include:
Your machine has less than 4GB of memory & you need to be stingy with what you've got.
You need to interface with a 32-bit only library on your computer for which you don't have access to a 64-bit version. I know of at least one ODBC driver that still fits this bill. Though for the customer that needs this I generally use perlapp to wrap up a dedicated 32-bit .exe file.
Related
I have a Windows 10 system with limited storage space - and am looking for an implementation of perl that will take up as little space on the disk as possible.
I've been using Strawberry Perl - which uses about 500 MB.
My perl needs are minimal, but I may need to install a couple of cpan modules.
I found a "Tiny Perl" on SourceForge - but it hasn't been touched in years - so I'm reluctant to even try it.
Can anyone recommend a good solution here?
Thanks.
The Perl installed with Strawberry Perl, including all core and vendor modules and a few I installed myself, weighs in at 140 MB. When you say it uses 500 MB, you're including the build toolchain required to install modules in your total (e.g. gmake, mingw, etc). This is something added by Strawberry and isn't part of Perl, and isn't required in day-to-day use of Perl.
Similarly, not all of that 140 MB is needed by everyone. A chunk of that is also part of the toolchain required for installing modules (e.g. ExtUtils::MakeMaker, etc).
To get a smaller footprint, you could build your own Perl, or keep only the perl/ subdir of a SP install, and surgically remove core modules you don't want from that.
For example, you could install SP (along with any modules you want) on a machine with sufficient disk space, then copy over just the perl/ subdir (minus the modules you want to omit) to the limited machine.
In determining what modules to remove, you could consult any of a number of linux distros that split Perl into a base package and the remainder.
I get the following error while trying to build code on a 64bit machine.
Can't load '/e/pkgs/linux/intel/perl/5.8.0/lib/site_perl/5.8.0/i686-linux/auto/XML/LibXML/Common/Common.so'
for module XML::LibXML::Common: libxml2.so.2: wrong ELF class: ELFCLASS64
at /e/pkgs/linux/intel/perl/5.8.0/lib/5.8.0/i686-linux/DynaLoader.pm line 229.
at /e/pkgs/linux/intel/perl/5.8.0/lib/site_perl/5.8.0/i686-linux/XML/LibXML.pm line 11
The perl is 32bit, but I have both 32 and 64bit versions of libxml2.so.2 on my machine. Is it trying to use the 64bit version of libxml2?
The library you are failing to load is one that supports the Perl XML::LibXML::Common module, not the libxml2 library. Most pure Perl modules are pretty portable across different versions of perl and even different platforms, but the binary files that sometimes support those modules are not, and you will get errors like this when you try to use a library that was built for one platform/version on another platform/version.
You will want to reinstall the XML::LibXML Perl distribution for your current system. Depending on how the wrong binaries got installed for your system, you may need to do this for several other distributions, too.
But before you do that, you might want to upgrade your version of Perl. Perl 5.8 is ancient, and Perl 5.8.0 is old even by the standards of Perl 5.8.
(running cpan XML::LibXML should reinstall that distribution for you)
This isn't my area of expertise so I'm asking hopefully the right question.
We have a server that is lease rolling. The old server is a 32-bit windows server and the new server is 64-bit windows 2008 R2 SP1.
One of the web applications uses Perl to run some scripts.
We can run the same 32bit version on the new 64-bit machine? (e.g. if there is a same version but one is 32-bit and one is 64-bit, are they essentially the same?)
If a script is working on a 32-bit version, should it still work under the 64-bit version of Perl?
If the questions need clarifying, please let me know and I'll see about asking the appropriate person on our team.
I think the answers to both your questions are yes. The 32-bit applications should run fine on your 64-bit Windows, but will not be able to utilize any of the 64-bit features (where a larger usable address space may very well be the most important if you ever want to parse big XML using XML::Twig ;-).
The script running under 32-bit perl will work on a 64-bit perl, provided you get all the modules for the 64-bit perl in order, since they typically run from different directories. Also, be aware that for 64-bit perl on Windows you probably need Strawberry perl, ActiveState perl or similar. Cygwin is only 32-bit as far as I know.
Yes, you can, as long as you redeploy properly, including the build steps for dependencies. Just copying files over will only work if the whole application stack is pure-Perl, which is not likely. — Yes, they are essentially the same, but binary incompatible.
Likely yes. Problems can arise with the dependencies, however the number of modules that fail due to 32-bit/64-bit differences are miniscule.
If you're concerned about compatibility, you should be able to run the 32-bit version of perl on the 64-bit machine (assuming both are x86). But the 64-bit version should work more or less the same as the 32-bit one, with a couple of exceptions that should not affect scripts. (They have to do with C/XS code in modules, mostly. Binary-compatibility stuff. Meaning modules will have to be built for 64-bit. Fortunately, any Perl interpreter that doesn't suck will do the build stuff for you in the case of *nix, or provide a package manager that has pre-built modules like ActiveState does.)
I just got my first 64-bit Windows notebook. Now I'm looking for information when and why to use the 32 or the 64-bit versions of PowerShell or ISE.
My first impression is that I better stay with 32 bit, until I understand things better.
What I miss or didn't find are basic tutorials and practical experiences and links to this questions.
I'am working on a Seven 64Bits and W2K8 R2 for one year now, and, on the command line, I'am always using 64 bits Powershell without any troubles.
For me the problem is not to choose 32 or 64 Bit PowerShell.exe, but to know that the two exists, and that a 32 bits process will use the 32 bits PowerShell. For example if you use PowerShell as post build execution script in Visual Studio 2010, it will use 32 bits PoweShell because Visual Studio 2010 is 32 bits process.
The two versions see two differents places in the registry so you have to Set-ExecutionPolicy for both.
As scripting is concerned I do not use ISE, but PowerGUI script Editor. You can use
[intPtr]::size
in a script to know if you are runing 32 or 64 bits PowerShell.exe.
You would use the 64 bit versions of PowerShell or PowerShell ISE where the problem you are trying to solve is uniquely 64 bit. For example:
You need your PowerShell script to be able to consume more memory than a 32 bit application will allow
You are consuming libraries that are 64 bit only or need to run in a 64 bit environment. For example on Windows 2008R2/IIS7.5 if you are using the Microsoft.Web.Management managed wrapper, if you need to modify administration.config via this library then your application or script needs to run in a 64 bit process.
I typically stick with 64-bit PowerShell unless I have a good reason to not use it. One issue with 32-bit PowerShell is that you may accidentally find yourself in HKLM:\SOFTWARE\Wow6432Node location of the registry instead of where you think you are.
The example I've most-often come across for an explicit need for 32-bit is when using certain COM objects. For example, if you have a 64-bit OS, but 32-bit Office... If you want to instantiate a Word, Excel, or Access object, you're going to need to be in 32-bit PowerShell or else it's going to act as if you don't have Office installed at all.
When running SharePoint 2013, it's important to run the 64-bit versions when attempting to user the Windows.SharePoint.PowerShell snapin. I spent too much time not realizing I had open the 32-bit ISE not being able to load SharePoint Commands.
I think you don't really need to take care about that. As for my 64bit system, there is only a 32bit PowerShell preinstalled (in \system32) and it works without any issues. So just use it ;) And well, besides that, it's most likely the same case as with any other application: if you rely on functions/properties that are only available under 64bit you are better of to use the 64bit version of that application.
I have access to a library with pre-compiled 32 bit mex files (Windows: .mexw32, Linux: .mexa32). I am having a hard time compiling the library myself for a 64 bit machine, so I was wondering if there is a way to make MATLAB 64 bit work with 32 bit mex files.
In general accessing 32bit code from a 64bit executable is nontrivial. Therefore I doubt they have implemented this in MATLAB natively...
No a 64-bit program cannot use 32-bit shared libraries. One option is to install the 32-bit version of MATLAB on your machine as well.