Roderich Schupp wrote: > On Tue, May 13, 2008 at 5:55 PM, Dave Howorth > <[EMAIL PROTECTED]> wrote: >> myscript: /lib/libc.so.6: version `GLIBC_2.3' not found (required by >> myscript) >> >> The production machine doesn't have any libc.so; it has /lib/libc.a > > It has /lib/libc.so.6 (as stated in the message). libc.so is only relevant > when > building (linking) programs, at runtime only libc.so.6 matters.
Aargh, rats! You're right of course. There's another machine in the chain and I mistakenly reported the state of its /lib. 'The' production machine does indeed have: -rwxr-xr-x 1 root root 5716491 Sep 4 2001 /lib/libc-2.2.4.so lrwxrwxrwx 1 root root 13 Sep 16 2002 /lib/libc.so.6 -> libc-2.2.4.so > The above message means: your perl 5.8.6 was built against a newer libc > and uses some features of it (tagged with symbol version GLIBC_2.3) > that are not present in the libc on the production machine. > Probably this holds not only for your perl binary, but also for your > pp'ed executable. > Try running > > readelf -s my.exe | grep GLIBC_2.3 That says: 171: 00000000 113 FUNC GLOBAL DEFAULT UND [EMAIL PROTECTED] (6) > If this produces any output, you're hosed - this executable simply will not > run > on the production machine. In theory, one could link my.exe statically... > If my.exe is OK, and it's just the special purpose perl packed into it > (which is extracted into /tmp/par-USER/...) you might get away by > including your libc.so.6 when pp'ing. Not that libm.so.6, libpthread.so.0 > and various libnss_*.so modules might also be affected. Hmm, I've tried both of these but I still get the same error: pp -c -o myscript -a "/lib/libc.so.6;/lib/libc.so.6" myscript.pl pp -c -o myscript -l /lib/libc.so.6 myscript.pl I don't see any pp options to build statically so I guess trying that would mean poking around with ld. I'll try that next. Cheers, Dave
