romm has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

I have a complex set of perl applications that interact with ClearQuest. On Windows 32-bit everything worked fine, but when we tried to migrate to 64-bit, we ran into the following difficulties we could not resolve:

1) If we run our applications via 64-bit Active Perl (v5.8.9) interpreter, with all modules installed as ppms, we cannot catch ClearQuest Windows object:

my $cq_session = Win32::OLE->new('CLEARQUEST.SESSION'); yields undef.

When I try to establish a connection to any other application, even CLEARQUEST.Application2, the session establishes fine, but CLEARQUEST.SESSION is out of reach. In 32-bit Windows it worked.

2) We contacted IBM/Rational and they told us they do not support this issue but we rather should use cqperl. cqperl is a v5.8.6 32-bit perl compiled by Rational and supplied with the whole ClearQuest package. However it lacks some modules we need, for instance DBI and DBD::ODBC, and Rational refuses to support their installation. So we tried to install them ourselves.

We needed compilation, so we put Visual Studio 2005. The compilation stage of DBI (and of DBD::ODBC) went fine, but on make test the things broke.

Make reported the following error:

Can't load 'c:/path/to/blib/arch/auto/DBI.dll' for module 
DBI: load_file:%1 is not a valid Win32 application at 
c:/path/to/CQPerl/lib/5.8.6/lib/DynaLoader.pm line XX.

[download]

Likewise error occurs if we ignore test errors and make install, but "Can't load" now points to the correct path of DBI.dll within CQPerl tree. (And the dll is present!) Same happens with DBD::ODBC.

cl (VC compiler) was tried in x86 (32-bit) mode. In 64-bit mode compilation failed on linking stage.

Can anyone advise either on 1) or 2) (1 is the preferrable way)
Thanks in advance,
Roman.

Replies are listed 'Best First'.
Re: Perl/ClearQuest or CQPerl/DBI on XP 64-bit
by BrowserUk (Patriarch) on Aug 05, 2009 at 16:48 UTC

    Please note, I know nothing of ClearQuest!

    You are using OLE, and OLE loads dlls and then calls functions within them. You cannot load a 32-bit DLL from a 64.bit process.

    So, unless IBM/Rational supplied you with 64-bit version of their interface components; or the sources so that you can build your own 64-bit versions, you are probably out of luck trying to use it from a 64-bit Perl.

    Stick with a 32-bit version of Perl, they run fine under win64.

    You could either:

    • stick with their supplied version of perl, and add your own modules to it.

      This appears to be what you tried to do when you got 

      Can't load 'c:/path/to/blib/arch/auto/DBI.dll' for module DBI: 
load_file:%1 is not a valid Win32 application at 
c:/path/to/CQPerl/lib/5.8.6/lib/DynaLoader.pm line XX

      [download]

      It looks like the problem is that you had VC set up to do 64-bit builds. You need to use SetEnv.cmd to configure for 32-bit builds.

      Alternatively, you could try using AS PPDs of DBI etc. with it. You would have to installl them manually (unzip and move the files), but it isn't too hard to do. You could even automate it.

    • Ditch their Perl and use a home-built (32-bit) or pre-compiled (32-bit).

      You would have to copy their bits into your libs tree which might be an awkward process.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

      Regarding the copying of AS PPDs into CQ installation. Wouldn't there be some path problem, as well as version mismatch problem? Or I should pick AS perl 5.8.6, just like the CQ perl is?

[reply]
        Regarding the copying of AS PPDs into CQ installation. Wouldn't there be some path problem

        I'm not sure what you mean by "path problem"? You would have to move/copy the files (manually) extracted from the AS .zips into the appropriate places with the CQPerl subtrees. This is generally not hard to do manually, though it begs to be automated.

        as well as version mismatch problem?

        So long as you fetch the AS .zip compatible with the build of CQPerl, it should be fine. Eg. If the CQPerl reports it's version as 5.8.x then get the zips from here.

        In general (though not guarenteed), dlls built with any compiler, for a given major release of Perl will interoperate correctly,

        Or I should pick AS perl 5.8.6, just like the CQ perl is?

        Are you saying that CQPerl is just a binary copy of AS Perl with some extra packages added? If so, does it come with ppm, or ppm-shell?

        If so, then just using that to install the extra packages you want would be by far the simplest option.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
Re: Perl/ClearQuest or CQPerl/DBI on XP 64-bit
by Anonymous Monk on Aug 05, 2009 at 11:42 UTC
    First nmake realclean then show output of 
    perl Makefile.PL && nmake test

    [download]
[reply]
[d/l]
[select]
      Are you sure that is neccessary? I have a bit of a difficulty obtaining it right now. The machine it is happening on is offline and I am not at the office.

      What kind of information you hoped to obtain? Maybe I can provide it.

      R.

[reply]

        I cannot help with 1 and for 2, I think Anonymous Monk is right. I would need to see the Makefile.PL output, build process and test output to have any idea what is wrong. I have both DBI and DBD::ODBC working with Activestate and I built them myself so I know you can do it with stock components.

[reply]
        This is where to start. DBI.dll is corrupt somehow, so first we examine process that produced DBI.dll
[reply]

Back to Seekers of Perl Wisdom