Re: Unable to run the exe on a non build machine
On Mon, 2003-10-20 at 22:03, [EMAIL PROTECTED] wrote: On Mon, Oct 20, 2003 at 03:13:22PM +0200, Markus Jansen wrote: On Fri, 2003-10-17 at 15:31, [EMAIL PROTECTED] wrote: Actually, executing a PAR-packed exe works like this - Autrijus correct me if I got this wrong: (1) exe creates a temp directory (2) exe writes to files into this temp directory: the shared perl library (e.g. libperl.so) and a small executable called par; these files get extracted from C char[] arrays inside the executable (3) exec then sets LD_LIBRARY_PATH to the temp direcctory and execs par with one argument: the name of the executable (4) par is actually a mini-perl (linked against libperl.so), that does some stuff in C, then eval's a Perl script contained in par (5) this script extracts all modules that a required for PAR.pm to work from the executable; the script can't use any modules The problem is (5) above: PAR.pm uses Archive::Zip which uses Compress::Zlib which has ashared library Zlib.so that links to libz.so. Everything is there EXCEPT libz.so. snip This is entirely correct. May I re-use it in the documentations? :-) Maybe the solution would be a Compress::Zlib::Static, which is just like Compress::Zlib but is guaranteed to statically link zlib inside, so we can safely distribute it to machines without zlib. Here's another suggestion: Instead of three methods to extract stuff from the executable: (1) stuff contained in char[]'s (2) poking around in the executable file with pure Perl (3) treat the executable as a zip file with PAR/Archive::Zip replace (1)+(2) with a hacked up version of the self-extracting zip-archive code that comes with the InfoZIP distribution. Of course, this will only work if this first-level zip also contains libz.so, so PAR (or Module::ScanDeps) needs a new feature: Pack shared libs that are referenced from a module's shared lib. Getting this information is of course highly OS specific, but should at least be easy on systems using the ELF object format (Linux, Solaris, *BSD?): - run ldd on the module shared library and parse its output - filter out system shared libs, e.g. libc, libm, libdl, on Solaris also stuff from /usr/platform/... Cheers, Roderich
RE: Unable to run the exe on a non build machine
On Fri, 2003-10-17 at 15:31, [EMAIL PROTECTED] wrote: Roderich, I get the same error even after adding libz.so. The script I am converting is an interactive script. When I run it on the machine where I built it and interrupt it while it's runnig, I can see in the /tmp/par_privtmp/ directory all *.pm files including the libz.so. I read that the LD_LIBRARY_PATH will modified to include this temp directory. Any idea how I can debug this? Raj, I dug a little deeper (using truss and the PAR source) and found that explicitly packing libz.so won't help, because it is already needed for unpacking the PAR (i.e. zip) archive that's included in the executable. Actually, executing a PAR-packed exe works like this - Autrijus correct me if I got this wrong: (1) exe creates a temp directory (2) exe writes to files into this temp directory: the shared perl library (e.g. libperl.so) and a small executable called par; these files get extracted from C char[] arrays inside the executable (3) exec then sets LD_LIBRARY_PATH to the temp direcctory and execs par with one argument: the name of the executable (4) par is actually a mini-perl (linked against libperl.so), that does some stuff in C, then eval's a Perl script contained in par (5) this script extracts all modules that a required for PAR.pm to work from the executable; the script can't use any modules (6) the extracted stuff is somewhere packed into the executable, but NOT in the included PAR; esp. this stuff is NOT zipped, as extracting it would require libz (7) (5) should no have produced an environment (in the temp directory) so that PAR.pm can run, finally control is transferred to PAR.pm to extract and execute your original script that's contained in the PAR (i.e. zip) file that is the executable (8) all modules/shared libs needed by the script are either extracted internally (for modules, by hooking into @INC) from the PAR, or are extracted upfronm into the temp directory (for shared libraries, because the are loaded by the system's shared library loader) The problem is (5) above: PAR.pm uses Archive::Zip which uses Compress::Zlib which has ashared library Zlib.so that links to libz.so. Everything is there EXCEPT libz.so. If you explicitly pack it, it would be extracted in (8), but execution never gets there because it bombs out in (7) because of the missing libz. So for now, there's nothing you can do, PAR needs to be fixed. Cheers, Roderich
RE: Unable to run the exe on a non build machine
Hi Roderich, my ultimate solution to this clash so far was to build Zlib.so with all .o files from libz.so around, and modifying the Makefile a little bit (I think there is also a lately added option in Compress::Zlib to build libz in the same run (of course only if it cannot be found), but I have not tried this). This way I get a self-contained Zlib.so. But of course you are right, the problem should be addressed from the PAR side. Best regards, Markus Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Subject: RE: Unable to run the exe on a non build machine From: Roderich Schupp [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: Mon, 20 Oct 2003 14:06:35 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Check-By: one.develooper.com X-Spam-Status: No, hits=-1.2 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,MAY_BE_FORGED,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFE RENCES,SPAM_PHRASE_00_01 version=2.44 X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/ On Fri, 2003-10-17 at 15:31, [EMAIL PROTECTED] wrote: Roderich, I get the same error even after adding libz.so. The script I am converting is an interactive script. When I run it on the machine where I built it and interrupt it while it's runnig, I can see in the /tmp/par_privtmp/ directory all *.pm files including the libz.so. I read that the LD_LIBRARY_PATH will modified to include this temp directory. Any idea how I can debug this? Raj, I dug a little deeper (using truss and the PAR source) and found that explicitly packing libz.so won't help, because it is already needed for unpacking the PAR (i.e. zip) archive that's included in the executable. Actually, executing a PAR-packed exe works like this - Autrijus correct me if I got this wrong: (1) exe creates a temp directory (2) exe writes to files into this temp directory: the shared perl library (e.g. libperl.so) and a small executable called par; these files get extracted from C char[] arrays inside the executable (3) exec then sets LD_LIBRARY_PATH to the temp direcctory and execs par with one argument: the name of the executable (4) par is actually a mini-perl (linked against libperl.so), that does some stuff in C, then eval's a Perl script contained in par (5) this script extracts all modules that a required for PAR.pm to work from the executable; the script can't use any modules (6) the extracted stuff is somewhere packed into the executable, but NOT in the included PAR; esp. this stuff is NOT zipped, as extracting it would require libz (7) (5) should no have produced an environment (in the temp directory) so that PAR.pm can run, finally control is transferred to PAR.pm to extract and execute your original script that's contained in the PAR (i.e. zip) file that is the executable (8) all modules/shared libs needed by the script are either extracted internally (for modules, by hooking into @INC) from the PAR, or are extracted upfronm into the temp directory (for shared libraries, because the are loaded by the system's shared library loader) The problem is (5) above: PAR.pm uses Archive::Zip which uses Compress::Zlib which has ashared library Zlib.so that links to libz.so. Everything is there EXCEPT libz.so. If you explicitly pack it, it would be extracted in (8), but execution never gets there because it bombs out in (7) because of the missing libz. So for now, there's nothing you can do, PAR needs to be fixed. Cheers, Roderich -- Markus Jansen Senior IS/IT Support Engineer, EED/IT Ericsson Eurolab Deutschland GmbH Email : [EMAIL PROTECTED] Ericsson Allee 1 Phone : +49 2407 575 5157 52134 Herzogenrath Fax : +49 2407 575 7289 GermanyMobile: +49 172 274 2003
Re: Unable to run the exe on a non build machine
On Fri, 2003-10-17 at 00:28, [EMAIL PROTECTED] wrote: Hi, I use perl 5.8.0 and par 0.75. We have a network installation of perl in /tools/sunos/perl58, where I built an executable. I am having trouble running this executable built on a machine in a different network. This machine has perl 5.6.1 installed in /usr/local, and do not have PAR installed on it (Should not matter really). Looks like it's not able to load the shared library libz.so . I see following message Does the machine where it's failing have libz.so installed? Note that pp currently does *not* pack additional shared libraries that are referenced from the Perl modules it packs, e.g. Compress/Zlib.so (which gets packed) refers to libz.so (which doesn't). For now you can explicitly add libz.so to the executable: - find Zlib.so where your perl modules are installed - run ldd on it and note the location given for libz.so: libz.so = /foo/bar/libz.so - use option -l for pp: pp -l /foo/bar/libz.so -o ... Cheers, Roderich
RE: Unable to run the exe on a non build machine
Roderich, I get the same error even after adding libz.so. The script I am converting is an interactive script. When I run it on the machine where I built it and interrupt it while it's runnig, I can see in the /tmp/par_privtmp/ directory all *.pm files including the libz.so. I read that the LD_LIBRARY_PATH will modified to include this temp directory. Any idea how I can debug this? Thanks -Raj -Original Message- From: Roderich Schupp [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2003 4:02 AM To: [EMAIL PROTECTED] Subject: Re: Unable to run the exe on a non build machine On Fri, 2003-10-17 at 00:28, [EMAIL PROTECTED] wrote: Hi, I use perl 5.8.0 and par 0.75. We have a network installation of perl in /tools/sunos/perl58, where I built an executable. I am having trouble running this executable built on a machine in a different network. This machine has perl 5.6.1 installed in /usr/local, and do not have PAR installed on it (Should not matter really). Looks like it's not able to load the shared library libz.so . I see following message Does the machine where it's failing have libz.so installed? Note that pp currently does *not* pack additional shared libraries that are referenced from the Perl modules it packs, e.g. Compress/Zlib.so (which gets packed) refers to libz.so (which doesn't). For now you can explicitly add libz.so to the executable: - find Zlib.so where your perl modules are installed - run ldd on it and note the location given for libz.so: libz.so = /foo/bar/libz.so - use option -l for pp: pp -l /foo/bar/libz.so -o ... Cheers, Roderich
