also, re the platform, it is Mandrake 8.2 with many additional bells and whistles.
re the relocation error i did find this on the net which was interesting...
----------------------------------------------------------
Most likely Mandrake's python was not using the RTLD_GLOBAL hack that Red Hat Linux had. If libimlib-jpeg.so needs a symbol called "_gdk_malloc_image", it needs to have a DT_NEEDED entry that says what library to get it from. (i.e., it needs to include -lgdk on the link line)
As you can see:
[msw@sid msw]$ ldd /usr/lib/libimlib-jpeg.so
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4001a000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
This would be OK if libgdk_imlib.so linked against libgdk, but:
[msw@sid 8.0]$ ldd /usr/lib/libgdk_imlib.so
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4003c000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40046000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4005d000)
libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4006b000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4008f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
libdl.so.2 => /lib/libdl.so.2 (0x4016c000)
So it's all totally broken. The RIGHT thing to do is fix gdkimlib. I
think it would be much easier to make your application use gdkpixbuf
which doesn't suffer these coding errors.
Cheers,
Matt
-----------------------------------------------------
So Mandrake have been known to make a mess of their linking from time to time.
But the output of ldd on my nsd is
: jss: 22:23:49 /usr/local/src/gui/tcl/tcl8.4.2/unix ; ldd /usr/local/progs/aolserver/bin/nsd
/usr/local/tcl/tcl8.4.2/lib/libtcl8.4.so => /usr/local/tcl/tcl8.4.2/lib/libtcl8.4.so (0x40016000)
libnsd.so => /usr/local/progs/aolserver-cvs/lib/libnsd.so (0x400b8000)
libnsthread.so => /usr/local/progs/aolserver-cvs/lib/libnsthread.so (0x40105000)
libdl.so.2 => /lib/libdl.so.2 (0x4011f000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40122000)
libm.so.6 => /lib/libm.so.6 (0x40138000)
libc.so.6 => /lib/libc.so.6 (0x4015a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
So I cannot see how there can be any problem finding TclCompileScript@tclByteCodeType, as tcl8.4.2.so DOES look like it has been linked in properly and I expect TclCompileScript should actually be in tcl8.4.so itself, and not require anything else to be linked in at run-time...
Maybe TclCompileScript has been left out of the library, though that seems very very unlikely to me or tcl would have failed many tests. I may try to find that symbol in tcl8.4.so to check on that though. Maybe its something to do with the "@tclByteCodeType" bit at the end.
argh.
I hope tcl8.4.1 works, because all i want to do is run AOLserver, not fix tcl8.4.2
John