in reply to Re: ActivePerl Problems
in thread ActivePerl Problems

The proxy is authenticated, but the authentication is a "secret." IE: The name of the proxy server, the UID used, and the password are all unknown, and corporate policy is, they won't let us know any of them. So "direct" HTTP is impossible.

By "hacked install," I mean that the ActivePerl MSI is installed just fine, but the Tk, DBI, and DBD::ODBC drivers were simply "copied in", e.g. from ".../blib/lib/*.pm" to ".../perl/lib/*.pm", directory tree intact.

The access violation seems to say to me that one of (DBI.DLL?, PERL.EXE, PERLCRT.DLL) is mismatching the versions of the others; but the DBI.tar.gz was just pulled today from ActiveState.Com/packages/x86, so I don't know how that's possible...

Replies are listed 'Best First'.
Re: Re: Re: ActivePerl Problems
by Fastolfe (Vicar) on Dec 03, 2001 at 22:28 UTC

    I would agree that your assumption about mismatched binary versions is the likely culprit, but I don't know that I can recommend an easy way to fix it without doing a proper install.

    You may want to try copying the entire Perl tree from one system to another. I don't know if ActivePerl would have a problem with that.

    Can you download the binary versions of these modules directly from ActiveState's web site? Do you have a support agreement with them that you can use to get an alternate installation path for these?

    (And off-topic for a second, how does your HTTP proxy work with IE if you don't know the username/password of the proxy? Don't you have to type it in? Or is it a special version of IE that hides this information and sends it secretly in the background without your knowledge? I've just never heard of a configuration like this before. Maybe your technical staff there can help you with finding another way of getting this application through your HTTP proxy? If they're forbidding the traffic, then they need to be prepared to have you incur these additional expenses in getting stuff like this to work... Just my 2 cents.)