On Mon, Feb 14, 2011 at 4:31 PM, Michael Miller <[email protected]> wrote: > Here's the output from the 'readelf' command: > > Dynamic segment at offset 0xf040 contains 20 entries: > Tag Type Name/Value > 0x00000001 (NEEDED) Shared library: > [/usr/lib/perl5/5.8/i586-pc-sco3.2v5.0/CORE/libperl.so]
Yikes. I really don't know why your gcc etc toolchain hardwires the full path to libperl.so into ./par when invoked as gcc main.o my_par_pl.o -s -Wl,-Bexport /usr/lib/perl5/5.8/i586-pc-sco3.2v5.0/auto/DynaLoader/DynaLoader.a -L/usr/lib/perl5/5.8/i586-pc-sco3.2v5.0/CORE -lperl -lsocket -lm -lcrypt -lc -o ./par That's, err, most unusual, to be polite. In fact, your gcc likes to hardwire all shared library references. That explains why you get the "can't open.." error message: the above par is actually stuffed into any packed executable, together with a copy of libperl.so. Both have been already extracted to the cache area (/tmp/par-USER/SHA1CHECKSUM or such) and then par is executed with LD_LIBRARY_PATH=<cache area> in the environment. So we expect that libperl.so will be found via LD_LIBRARY_PATH. But since its location is hardwired this won't work. Sorry, there's nothing I can do on the PAR::Packer side. If you know the right incantation to stop gcc hardwiring library references, patch the above line in myldr/Makefile and let me know. Cheers, Roderich
