It turns out my customer's Linux box has the Expat library incorrectly configured somehow. The solution is to add "--link=expat" to the pp invocation.
Many thanks for the suggestions I got. I would not have worked through this without them. Details ... My customer definitely does not have /usr/lib/libexpat.so.0. The strace shows that file failing to open. He claims to have /usr/lib/libexpat.so. I don't know why that file name is never tried. The Linux box where the pp build occurs has both libexpat.so and libexpat.so.0. You get the error message below when Expat.pm is correctly installed but the libexpat library is not. You can see it yourself by temporarily renaming the libexpat library names. On Windows, temporarily rename C:\Perl\lib\auto\XML\Parser\Expat\Expat.dll (or some similar location). The pp option --link=<libname> says to include that library in the package. In my case, --link=expat does the trick. I only need to do this for Linux builds. On Windows builds, the file Expat.dll is already included by default. Thanks and regards, -George -----Original Message----- From: Roderich Schupp [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 02, 2008 3:06 AM To: Mock, George Cc: par@perl.org Subject: Re: executable fails on some Linux boxes On Tue, Apr 1, 2008 at 11:43 PM, Mock, George <[EMAIL PROTECTED]> wrote: > The executables work fine on Windows and Linux machines. Except one > customer of mine, who is running a Linux executable, see this error: > > Can't locate object method "new" via package "XML::Parser" at > XML/Simple.pm line 404, <STDIN> line 1. > > I asked the customer to zip up the /tmp/par-username directory and send > it to me. I cannot find anything amiss in it. In particular, when I > look at the file Parser.pm I plainly see the line ... > > sub new { > > So, I'm stuck. I'd appreciate any thoughts on what I should try next. Advise your customer to run your executable under strace strace -f -o strace.out -e trace=file,process your.exe ... and send you strace.out. I suspect that either your pp'ed executable is missing something that's accidentically present on all machines except this customer's or it's something that is accidentically present only on this machine, but in an incompatible version, and taking precedence over the version packed into the executable. So I would examine strace.out for files pulled in (i.e. an open() call that succeeds) from outside /tmp/par-USER (ruling out the expected, e.g. /lib/libc.so.6) and also failing "searches", i.e. consecutive unsuccessful open() calls for the same file in different directories that don't end with a successfull open(). Since XML::Parser::Expat is involved I would especially check which libexpat.so.? is pulled in and whether it cleanly resolves with the packed XML/Parser/Expat.so - Perl's dynamic loading of shared libraries is known to fail sometimes without throwing an appropriate error. Cheers, Roderich
