Upgrading from 32 bit ActivePerl-5.8.8.817 to 64 bit ActivePerl-5.8.8.819

[Ted]

I get the upgrade instructions from an earlier version of ActivePerl to
the current one. I found the following:

Use Window's Add / Remove Programs applet (accessible from the Control
Panel) to uninstall ActivePerl.
Manually delete all directories beneath the Perl installation directory
(by default C:\Perl) except the site\lib directory.
Install ActivePerl to the same directory (i.e., C:\Perl).
Use the ppm upgrade command to check for module updates.

This seems easy enough, but I see no mention of upgrading from a 32 bit
version to a 64 bit version.

I am running 64 bit Windows XP on an AMD Turion64 based notebook.

My question is this. The instructions for upgrading I found were in
documentation provided with the 32 bit version. If I am going to 64
bit from 32 bit, do I need to do anything differently? Is the PPM
upgrade smart enough to know I was running the 32 bit version and now
want to run the 64 bit version and get the 64 bit versions of allthe
modules I'd installed? Or do the modules care about whether the
hardware is 32 bit or 64 bit (much like my java programs don't care
about it since they get compiled to bytecode which is supposed to be
platform independant). I know perl is interpreted, and any modules
I've made have been stored as source code; hence the question.

Thanks

Ted

 

[Sisyphus]

No.

I think things *do* need to be done differently

It would be more accurate to say that PPM neither knows nor cares what you
might have previously had installed. It simply downloads whatever modules
are appropriate for what you currently have, whether that's 32- or 64-bit.


Pure Perl modules don't care. XS and/or Inline::* modules that include a
binary (i.e. compiled) component do care.

Herein lies the reason that things need to be done differently. The OP is
following instructions that told him to leave the current (32-bit)
perl/site/lib directory in place. It is most likely that directory contains
32-bit binaries that will not work with 64-bit perl.

In this particular instance, I believe the OP needs to do a complete fresh
install - ie *compleletely* remove the current perl (including
perl/site/lib), then install the 64-bit version. This means that any
required modulesin the current 32-bit build, that are not included as
standard with AS perl, will be lost - and they'll have to be installed into
the 64-bit version(eg by using PPM).

Cheers,
Rob

 

[Ben Morrow]

It would be more accurate to say that PPM neither knows nor cares what you
might have previously had installed. It simply downloads whatever modules
are appropriate for what you currently have, whether that's 32- or 64-bit.

Is that true? For example, if the OP had Foo-Bar v1.25 installed, and
this was the latest version, would PPM know that it needed to reinstall
it anyway as the archname has changed? I suspect not, as ActivePerl
doesn't use the site_perl/5.8.8/i686-MSWin32/ convention for
arch-dependant modules.

To the OP: I would advise making a list of the packages you have
installed (the new GUI ppm makes that really easy), then deleting the
whole lot, including the site directory, and reinstalling those modules
through ppm afterwards.

Ben

 

[Ben Morrow]

Sorry, I missed the "except perl/site" part. :-(


I wouldn't expect the 64-bit perl to have the 32-bit archlib in its @INC
to begin with, even if both are somewhere under perl/site/lib. So, I
installed ActivePerl to have a look - I can't believe my eyes. No archdir.

I honestly hadn't imagined it could be *that* broken.

It's not really 'broken'. It is, in fact, the default way of installing
Perl under Windows (i.e. if you build it from source). Until really
quite recently the chance of an AS installation being shared between
machines of different archs was practically nil.

It might be worth filing a bug, though, now they provide 32 and 64 bit
builds. There might be good reasons for having both on the same machine
(or the same network). C:\Perl\bin becomes an issue, though: they would
probably have to make it C:\Perl\bin64 for 64-bit Perl, which could
become confusing.

Yeah, given the broken way that ActiveState has apparently configured it,
nuking the site/ from orbit is the only safe option.

Does ppm have an equivalent to CPAN's autobundle command?

Ben

 

[Sisyphus]

I get the upgrade instructions from an earlier version of ActivePerl to
the current one. ..
..

This seems easy enough, but I see no mention of upgrading from a 32 bit
version to a 64 bit version.

If you're planning on using PPM, then it would be a good idea to consider
the possibility that ppm packages might not be so readily available for
64-bit Windows. The 'bribes' and 'uwinnipeg' repositories provide ppm
packages for a number of modules that are missing from the ActiveState
repository. But the 'bribes' and 'uwinnipeg' reps are strictly 32-bit
(afaik) and therefore won't be of any help to you. You'll be limited to
what's available from ActiveState - which may have little impact on you
(depending on which packages you want) - but it's something best considered
in advance.

Cheers,
Rob

 

[Ted]

OK, It looks like I might be a little crippled.

I did the upgrade after I saw the first response. SO now it looks like
I'll have to blow everything away and reinstall. But it looks like PPM
will be useless for a while. On starting it, I see the following:

C:\>ppm
The PPM graphical interface is not available for this Perl
installation.
Run 'ppm help' to learn how to use this program as a command line tool.

C:\>

And then when checking the repositories, I see:
C:\>ppm repo list
+--------------------------------------------+
¦ id ¦ pkgs ¦ name ¦
+----+------+--------------------------------¦
¦ 1 ¦ 0 ¦ ActiveState Package Repository ¦
+--------------------------------------------+
(1 enabled repository)

C:\>


If I am interpreting this right, there is virtually nothing in
ActiveState's ppm repository for 64 bit systems. And I get the
following when I look for more repositories:

C:\>ppm repo suggest
ppm repo add activestate
ActiveState Package Repository
http://ppm4.activestate.com/MSWin32-x64/5.8/819/

*** Install PPM-Repositories for more suggestions ***

But "PPM-Repositories" doesn't seem to exist. PPM doesn't find it and
cpan doesn't know about it.

So, I guess, I am limited to those packages that are pure perl and
available through CPAN. If there are some written primarily in C++, I
suppose I may be able to compile them to a 64 bit binary using Visual
Studio 2005. BTW, how would I tell PPM or CPAN that I have Visual
Studio, so they know where to find the compiler and nmake. I can't add
the folders that contain them to the path because there are a number of
versions (e.g. both 32 bit and 64 bit - I don't know if the version
used affects anything, but I don't want to break anything).

Can you think of anything that might help make this a bit easier? Is
there an easy way to tell CPAN to look for only packages written
entirely in Perl, or which are available as 64 bit packages? Or do I
just download them without installing them and look at what I get?

Thanks

Ted

 

[Ben Morrow]

OK, It looks like I might be a little crippled.

So, I guess, I am limited to those packages that are pure perl and
available through CPAN. If there are some written primarily in C++, I
suppose I may be able to compile them to a 64 bit binary using Visual
Studio 2005.

MSVC is (or pretends to be) a C compiler as well as a C++ compiler, you
know.

BTW, how would I tell PPM or CPAN that I have Visual
Studio, so they know where to find the compiler and nmake. I can't add
the folders that contain them to the path because there are a number of
versions (e.g. both 32 bit and 64 bit - I don't know if the version
used affects anything, but I don't want to break anything).

You need to add just the appropriate folders to your path, but just
while you run CPAN.pm. It's quite important to get it right, and make
sure you haven't got anything else in your path. ActivePerl has a
'feature' whereby if it detects dmake or gcc in your path it will assume
you want to use those and will modify Config.pm on the fly to return
appropriate values; except it gets it really quite wrong, and several of
the settings are not modified as they should be.

That said, if you correctly set the path so that 64bit versions of cl,
link, nmake, and maybe rc and cvtres are found first; create a lib.bat
as described in perlwin32; and set INCLUDE and LIB appropriately (again,
see perlwin32: basically, you need all the headers and all the libraries
from VC7, the platform SDK, and the .NET SDK) then you should be
able to use CPAN.pm to install even XS modules. Note that I've never
tried linking AS perl (built with VC6) with extensions built with VC7:
it's possible there may be problems with MSVCRT.dll.

You may find it easier to build perl from source with VC7: it's really
not hard. You just set things up as described in perlwin32, edit a
couple of options in win32/Makefile and set it going.

Can you think of anything that might help make this a bit easier? Is
there an easy way to tell CPAN to look for only packages written
entirely in Perl, or which are available as 64 bit packages?

Well, if you make sure cl is not in your PATH then any attempt to build
an XS module will fail.

Ben

 

[Sisyphus]

..
..
..

If I am interpreting this right, there is virtually nothing in
ActiveState's ppm repository for 64 bit systems.

That may be ... I'm not sure. Best place to seek complete and sound advice
about what's available for 64 bit (and where to get it) is probably the PPM
mailing list. Visit http://listserv.ActiveState.com/mailman/mysubs
to subscribe.

So, I guess, I am limited to those packages that are pure perl and
available through CPAN.

No - if you have a 64-bit Microsoft compiler (as is apparently the case) you
can use it to build those modules that require compilation.

If there are some written primarily in C++, I
suppose I may be able to compile them to a 64 bit binary using Visual
Studio 2005.

Visual Studio will handle C, as well as C++.

BTW, how would I tell PPM or CPAN that I have Visual
Studio, so they know where to find the compiler and nmake. I can't add
the folders that contain them to the path because there are a number of
versions

The 2 versions of Visual Studio that I have (6.0 and 7.0) both come with a
batch file in their 'bin' folder called 'vcvars32.bat'. I just run, from the
command line, the appropriate vcvars32.bat (depending upon which compiler I
want to use) and that sets the path and other environment variables
appropriately (for the *current* shell only .... the system-wide path
setting and env vars are unaffected).

If your compiler has such a batch file, you could do the same. Or you could
write your own batch file and run it whenever you want to use the compiler
of your choice. Or you could just make your alterations to the current
shell's env vars by typing in appropriate commands at the command line.

(e.g. both 32 bit and 64 bit - I don't know if the version
used affects anything, but I don't want to break anything).

I'm not sure which compiler AS use for their 64-bit builds. Is it Visual
Studio 6.0 (same as for their 32-bit builds ) ? If possible, use the same
version of Visual Studio that they use - though if you have to use a
different version of Visual Studio you'll still get good mileage. There can
be a problem when perl has been built with a compiler that uses one version
of the MS C runtime library, and your compiler uses a different version of
the MS C runtime - but that's a problem that arises only rarely, afaik.
(Win32::SharedFileOpen is the only module I know of that's affected by
this.)

Can you think of anything that might help make this a bit easier? Is
there an easy way to tell CPAN to look for only packages written
entirely in Perl, or which are available as 64 bit packages? Or do I
just download them without installing them and look at what I get?

Yep - just download them, and let your compiler handle the necessary
compilation.
Mostly, you shouldn't need to concern yourself with what's inside the
packages.

Cheers,
Rob