0

We're moving our old Perl/CGI application to a new system internally and ran into a snag. When I run:

 perl -MXML::Parser -e 1

From the command line, all is well. However, when I run it from a CGI script as use XML::Parser, all hell breaks lose:

Can't load 'C:/strawberry/perl/site/lib/auto/XML/Parser/Expat/Expat.dll' for module XML::Parser::Expat: load_file:The specified module could not be found at C:/strawberry/perl/lib/DynaLoader.pm line 200, line 55. at C:/strawberry/perl/site/lib/XML/Parser.pm line 18 Compilation failed in require at C:/strawberry/perl/site/lib/XML/Parser.pm line 18, line 55. BEGIN failed--compilation aborted at C:/strawberry/perl/site/lib/XML/Parser.pm line 22, line 55. Compilation failed in require at (eval 43) line 1, line 55. BEGIN failed--compilation aborted at (eval 43) line 1, line 55.

Other modules added onto the perl installation work fine (MD5, WIn32::ODBC, etc...) but this Expat one snarls.

The server is IIS 7 (new to us for this app), x64 Win2008 (also, new to us).

EDIT:

After futzing around with this for a while, this isn't the only module that fails to load. XML::Simple does as well. Almost the same error. The DLL's that Perl is claiming do not exist, exist just fine. And things work from the command line as well.

Suggestions?

Clinton Pierce
  • 186
  • 2
  • 10

2 Answers2

1

There is a bug in the perl distribution for Windows in Cwd.pm. See https://rt.cpan.org/Public/Bug/Display.html?id=56225 for details.

The fix that worked for me is to replace this line:

if (eval 'defined &DynaLoader::boot_DynaLoader') {

with

if (eval { defined &DynaLoader::boot_DynaLoader; }) {

in sub _win32_cwd

I also found more related information here: www.epic-ide.org/faq.php#debug

mynamedotcom
  • 11
  • 1
  • You may be completely right, I'm just having trouble putting the pieces together of why a bug in CWD that works on the command line stops working in CGI context. The guilty fingers both point in the general direction of Dynaloader, but I think one is a cause and the other is an effect.I did find a workaround (see below). – Clinton Pierce Oct 27 '10 at 13:59
0

Sorry to answer my own question, but I stumbled on this...

After hours of poking away at this, the problem turns out to be in the IIS ApplicationPool settings. If you have Load User Profile set to False then Perl's Dynaloader craps itself and nothing works -- and without particularly useful messages. I don't know which is the default, but having it false causes everything to fail.

So right now things are working nicely, and here are the settings in the Application Pool:

32-Bit: Enabled User: Application Pool Load User Profile: True

I found this by attempting to get the CGI programs to run as a real user (the one that I was using at the command-line) and noting that I wasn't getting the environment I wanted even though I had the right user set up. Flipping this switch caused everything to work. Eventually I went back to using Application Pool but confirmed this switch was the cause.

Clinton Pierce
  • 186
  • 2
  • 10