On Tue, Jul 22, 2003 at 07:09:04PM -0700, Jim Hayward wrote: > Running ldd on the binary didn't help either. Just says... "not a > dynamic executable" Can you run file /the/binary to verify it? Also, strace -e open -o /tmp/open.log /the/binary; cat /tmp/open.log would be helpful. Now, if it is really a statically linked binary which is dlopening libGL.so.1 and has been linked on some older system, I'd say this is more less expected. <speculation> The thing is, statically linked binaries doing dlopen, NSS lookups or iconv are the least portable thing in the OS (recent glibc even gives you a link time warning about need to recompile/relink statically linked binaries when moving to different glibc release if they use some of those). What they should have done is to link libraries not expected on the target system with -Bstatic ... -Bdynamic but link dynamically against libc, libm, libdl, libpthread, libGL and similar libraries. An old statically linked binary has of course no support for TLS in its dlopen, so it would be no surprise things crash (on the other side, it would surprise me things work if it dlopens /lib/tls/libc.so.6 indirectly, unless it doesn't really use it). Now, as a workaround, what IMHO should help for that program is IMHO LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X11R6/lib /the/binary The dynamic linker linked statically into that binary picks /usr/lib/tls/i686/libc.so.6 only because it is in ld.so.cache (due to bugs in it it ignores hwcap 0x8008000000000000). But with LD_LIBRARY_PATH, it should not search /tls/ subdirectories which are not known to it, so it should pick /usr/lib/libGL.so.1 (and /lib/i686/libc.so.6 or /lib/libc.so.6 etc.). </speculation> The above applies only if file command above output matches .*ELF.*statically linked.* and strace output includes those libraries. Jakub _______________________________________________ xfree86-list mailing list xfree86-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/xfree86-list IRC: #xfree86 on irc.redhat.com
