Il giorno 29/mar/05, alle 21:03, Andreas Jaeger ha scritto:
Riccardo Ghiglianovich <email@example.com> writes:
I have found that if I call an ELF32 Executable program from a php page loaded by a 64 bit PHP module then I obtain a shared library error, even if the program does not require the library.
I am sorry I have been a bit hasty...
this is the result of the test: /tmp/pro: error while loading shared libraries: /usr/lib64/GL/libGL.so.1: cannot open shared object file: No such file or directory
of course hello world does not require libGL.... however the /usr/lib64/GL/libGL.so.1 exists and is ok.
What does ldd /tmp/pro output?
It propmts nothing strange and nothing about LibGL $ ldd -v /tmp/pro linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/libc.so.6 (0x5557f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x55555000) Version information: /tmp/pro: libc.so.6 (GLIBC_2.0) => /lib/tls/libc.so.6 /lib/tls/libc.so.6: ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2 $ .... Strange things are happening... Last night I thougth "may be a LIB PATH problem.." so I encapsulated the exe in a shell script; so now the r.phtml calls pro.sh: =====pro.sh #!/bin/sh export LD_LIBRARY_PATH="/lib:/usr/lib" /tmp/pro ---- nothin :( I also changed pro.sh in ===== #!/bin/sh /usr/bin/ldd "/tmp/pro" ---- and the strange result is: /tmp/pro: error while loading shared libraries: /usr/lib64/GL/libGL.so.1: cannot open shared object file: No such file or directory why! /tmp/pro does not seems a ldd parameter!!! I do not understand... RIc