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

Discussion in 'Perl Misc' started by Ted, Dec 15, 2006.

  1. Ted

    Ted Guest

    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
    Ted, Dec 15, 2006
    #1
    1. Advertising

  2. Ted

    Sisyphus Guest

    "Sherm Pendley" <> wrote in message
    news:...
    > "Ted" <> writes:
    >
    > > 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?

    >
    > No.


    I think things *do* need to be done 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?

    >
    > 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.
    >
    > > Or do the modules care about whether the
    > > hardware is 32 bit 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
    Sisyphus, Dec 15, 2006
    #2
    1. Advertising

  3. Ted

    Ben Morrow Guest

    Quoth Sherm Pendley <>:
    > "Ted" <> writes:
    >
    > > 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?

    >
    > No.
    >
    > > 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?

    >
    > 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

    --
    I've seen things you people wouldn't believe: attack ships on fire off
    the shoulder of Orion; I watched C-beams glitter in the dark near the
    Tannhauser Gate. All these moments will be lost, in time, like tears in rain.
    Time to die.
    Ben Morrow, Dec 15, 2006
    #3
  4. Ted

    Ben Morrow Guest

    Quoth Sherm Pendley <>:
    > "Sisyphus" <> writes:
    >
    > > 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.

    >
    > Sorry, I missed the "except perl/site" part. :-(
    >
    > > It is most likely that directory contains
    > > 32-bit binaries that will not work with 64-bit perl.

    >
    > 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.

    > > 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.

    >
    > 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

    --
    Every twenty-four hours about 34k children die from the effects of poverty.
    Meanwhile, the latest estimate is that 2800 people died on 9/11, so it's like
    that image, that ghastly, grey-billowing, double-barrelled fall, repeated
    twelve times every day. Full of children. [Iain Banks]
    Ben Morrow, Dec 15, 2006
    #4
  5. Ted

    Sisyphus Guest

    "Ted" <> wrote in message
    news:...
    > 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
    Sisyphus, Dec 16, 2006
    #5
  6. Ted

    Ted Guest

    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
    Ted, Dec 16, 2006
    #6
  7. Ted

    Ben Morrow Guest

    Quoth "Ted" <>:
    > OK, It looks like I might be a little crippled.
    >

    <AS don't appear to provide 64-bit packages>
    >
    > 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

    --
    Outside of a dog, a book is a man's best friend.
    Inside of a dog, it's too dark to read.
    Groucho Marx
    Ben Morrow, Dec 16, 2006
    #7
  8. Ted

    Sisyphus Guest

    "Ted" <> wrote in message
    news:...
    ..
    ..
    ..
    > 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
    Sisyphus, Dec 16, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. marko
    Replies:
    0
    Views:
    1,086
    marko
    Jul 19, 2003
  2. WS
    Replies:
    0
    Views:
    665
  3. Replies:
    3
    Views:
    1,702
    Timothy Bendfelt
    Jan 19, 2007
  4. Replies:
    9
    Views:
    918
    Juha Nieminen
    Aug 22, 2007
  5. Jeff.M
    Replies:
    6
    Views:
    155
    Lasse Reichstein Nielsen
    May 4, 2009
Loading...

Share This Page