Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Perl 32-bit vs 64-bit question

140 views
Skip to first unread message

snorble

unread,
Feb 3, 2012, 11:01:52 AM2/3/12
to
When I have used Python 64-bit I have run into problems (third party
libraries not working, etc). So I just use Python 32-bit on everything
and have no problems. Are there any similar problems with Perl? On a
64-bit computer, am I better off with 64-bit, or better off running 32-
bit Perl on everything? I'm looking to use Perl on Windows systems for
administration purposes. Thank you for any guidance you can provide.
Message has been deleted

Ben Morrow

unread,
Feb 7, 2012, 2:32:14 AM2/7/12
to

Quoth Michael Vilain <vil...@NOspamcop.net>:
> In article
> <7e2122cd-2e89-4f88...@4g2000pbz.googlegroups.com>,
I'm running a 64bit perl on this machine with no problems, but then I'm
running FreeBSD so everything running on this machine was compiled on
this machine, in 64bit mode. Running under Windows where you potentially
need to deal with 3rd-party binary-only libraries is rather different.

I would expect 32bit perl to run without problems on Win64. According to
strawberryperl.com there are currently some important modules which will
not build in 64bit mode; probably the most important are the SSL
modules, none of which apparently currently build in 64bit mode under
Windows.

The most important question is whether there is anything in particular
you know you are going to need to use. If there is, you need to check it
will work with your chosen version of perl. However, I rather get the
impression you're just starting to learn Perl: in that case, I would
recommend going to http://strawberryperl.com and installing the default
version from there. Currently that is a 32bit build of 5.12.3, so I
would expect that to be the most reliable and generally useful version.

> I've always heard that a 64-bit executable can't load 32-bit shared
> libraries.

It is possible to load a 32bit library from a 64bit executable, but not
with the normal runtime linker under most OSs. A few programs like
mplayer have their own custom runtime linking code which allows them to
load 32bit Win32 libraries into a 64bit Unix process.

> I may be wrong with that in MacOS in that 10.6 (Snow
> Leopard) is 32-bit but can run 64-bit executables on a suitable
> processor.

10.6 has the whole OS available in both 32- and 64bit versions. (The two
versions live in the same files, using the same 'fat binaries' as
earlier versions used for Intel vs. PPC.) Many machines normally run a
32bit kernel even though their processors are 64bit-capable; this
doesn't stop you from running 64bit processes, since the 64bit libraries
are available.

> Windows 7 has two flavors--32-bit and 64-bit. The drivers
> have to be the same but I think programs don't matter as much unless you
> attempt to mix 32 and 64-bit libraries.

Yes. A device driver (or, at least, a device driver that runs in kernel
mode: Windows uses the term rather broadly) is essentially a shared
library to be loaded into the kernel. That means the word size has to
match. A suitably-written 32bit kernel can run a 64bit process, but only
if 64bit libraries are available.

> Mixing compiled shared libraries is the problem. I don't think this
> problem is only with Python. But I could be wrong.

There is nothing Python- (or Perl-) specific about any of this, no.

Ben

0 new messages