>>>>> On Tue, 12 Aug 2008 18:21:55 +0200, "Roderich Schupp" <[EMAIL PROTECTED]> >>>>> said:
>> FYI, I tried moving the above Zlib.so aside and it worked after that... >> so it is definitely loading the wrong Zlib package first. My guess is >> that the unzip process isn't setting the right path and @INC is changing >> later than the unziping process? >> RS> You probably did RS> pp -o foo -e 'print "[EMAIL PROTECTED] = @INC\n";' I used dumper instead, but yes. The results from yours looks fine too: @INC = /tmp/par-hardaker/cache-2731b515e3b717aaf2ccf5e8877661318c53315c/inc CODE(0x8e39404) CODE(0x8e38ea4) RS> The Compress::* modules are special in that they get extracted in an RS> earlier phase (because Archive::Zip needs them to extract stuff RS> from the PAR archive in the packed executable). So your guess may be RS> right. Yep.... I figured they must be the special case. RS> Another possibility is that some Compress::* modules might contain RS> hardcoded information that takes precedence, e.g. an RPATH RS> entry in one of the shared libraries. I doubt that since it's perl's module that is getting loaded. It's loading a perl shared object (not a shared library) and it's loading the system object instead of the packaged object. Not having looked at the code for PAR at all I'm not even sure how it's handling the chicken and egg problem so I'm not of much help unless I go dive in myself. Either way, right now it's loading the system shared object when it should be loading the internal one. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett
