On Tue, Jun 30, 2009 at 3:04 PM, Roderich Schupp<roderich.sch...@googlemail.com> wrote: > On Tue, Jun 30, 2009 at 12:11 PM, Thomas Maier<hay...@gmail.com> wrote: >>> Does it work? >> Amazingly (or not - I have no clue), yes ! > > OK, here's what I think is going on: > > (1) By construction a pp-packed executable sets (ELF-wise) RPATH and/or > RUNPATH > to wherever the shared Perl library (libperl.so or similar on Linux) > is installed on the packing machine (i.e. where PAR::Packer, pp etc live). > (This is not really intended, but the current build of PAR::Packer does it.) > This is harmless, since this executable isn't actually linked against > libperl.so. > > (2) A pp-packed executable works like this: > - in phase 1 it creates a temp directory and write some fixed > files into it (these files are stored in the exeutable itself as > large arrays) > (a) one such file is the shared libperl.so (or similar) from the > packing machine > (b) the other is a custom Perl interpreter and it is linked against (a) > (the file is given the same name as the invoking packed executable, > but it is NOT a copy of it) > - phase 2 consists of running (b) with environment variable > LD_LIBRARY_PATH set to the temp directory where > (a) has been extracted into; the custom Perl interpreter first > runs a script that will extract all necessary Perl modules > needed to do "use PAR" from the packed executable itself; > this script is rather tricky since it cannot use any modules at all > for its task > - in phase 3 the embedded script actually does "use PAR > '/your/packed/executable';" > - the packed excutable also contains a .par file at the end; > finally your original script is run from this .par > > (3) Your problem happens in phase 2: the custom Perl interpreter (b) > is also affected by (1), i.e. it sets RPATH/RUNPATH. But usually > LD_LIBRARY_PATH takes precedence over that and the "correct" > libperl.so (a) is found. strace shows that in your case this didn't > work (see below) and RPATH/RUNPATH took precedence. > Usually this would go unnoticed, since either this directory doesn't > exist or both machines have identical Perl installations so it doesn't matter. > Unfortunately there was actually something there on the test machine - > libperl.so from the Perl 5.8.8 installation there. Now > the rest of phase 2 probably went OK, extracting modules and shared > libraries. But these are from the Perl 5.8.5 packing machine. > It probably blew up when some of these modules where loaded > in phase 3, but running with the 5.8.8 libperl.so - there must be some > subtle incompatibilities there. > > hello2 from the above experiment works, because we patched it (and the > embedded (a)) so that RPATH/RUNPATH pointed to some non-existing directory; > hence LD_LIBRARY_PATH took effect as intended. > > Remains the question: Why didn't it in the first place? > "man 8 ld.so" explains the search order for shared libraries: > > - RPATH if set (and RUNPATH not set also) > - LD_LIBRARY_PATH > - RUNPATH if set > - stuff found in /etc/ld.so.cache > - system default, usually /lib, then /usr/lib > > If the executable is running setuid or setgid then LD_LIBRARY_PATH is ignored. > > As shown by "readelf -d packed-executable" my installation of PAR::Packer here > produces packed executables with both RPATH and RUNPATH set, > hence LD_LIBRARY_PATH will take precedence. Can you check your executable? First of all, thanks for this explanation. I see that mine is not: # readelf -d <my-executable> 0x00000001 (NEEDED) Shared library: [libresolv.so.2] 0x00000001 (NEEDED) Shared library: [libnsl.so.1] 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [libm.so.6] 0x00000001 (NEEDED) Shared library: [libcrypt.so.1] 0x00000001 (NEEDED) Shared library: [libutil.so.1] 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000000f (RPATH) Library rpath: [/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE] 0x0000000c (INIT) 0x8049a10 0x0000000d (FINI) 0x804d260
Just to emphasize what you've said, on the second station (WindRiver with 5.8.7) the RPATH directory does not exists and my executable does running there. So, the question now is, do we have some generic way to fix it ? I mean, more generic then deleting directories or fixing binary files. Thomas
