Hi all, I am new here;
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.
practical example:
compile this ====== pro.c #include <stdio.h>
main() {
printf("Hello world\n"); } ------ cc -o pro -m32 pro.c
then call it from a php page: ========= r.phtml <?php
$s = "/tmp/pro 2>/tmp/er 1>&2"; echo "$s : "; $rrr=exec($s); echo `cat /tmp/er`; echo "<hr>"; // just to test that it works... $s = "ls -al /tmp 2>/tmp/er 1>&2"; echo "$s : "; $rrr=exec($s); echo `cat /tmp/er`;
?> ---- http://localhost/r,phtml
issuee? Error?Bug? my fault??? Hints? I cannot recompile at 64 all my programs ...
Thanks, regards, Ric
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.
using cli php it runs good... :/ (/usr/bin/php /tmp/r.phtml)
Regards, Ric
Riccardo Ghiglianovich riccardo@logicalsystem.it 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?
Andreas
Il giorno 29/mar/05, alle 21:03, Andreas Jaeger ha scritto:
Riccardo Ghiglianovich riccardo@logicalsystem.it 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
Il giorno 30/mar/05, alle 09:12, Riccardo Ghiglianovich ha scritto:
/tmp/pro: error while loading shared libraries: /usr/lib64/GL/libGL.so.1: cannot open shared object file: No such file or directory
DONE :) I found in /etc/rc.d/apache:
# # work around libGL being non functional (#26665) at boot time # if [ "$HTTPD_SEC_MOD_PHP" = yes -a -e /usr/lib64/GL/libGL.so.1 ]; then
libgl_preload="LD_PRELOAD=${LD_PRELOAD:+$LD_PRELOAD:}/usr/lib64/GL/ libGL.so.1" fi
I dont know what is it for so I wont delete it... I have modified the pro.sh script: #!/bin/sh unset LD_PRELOAD /tmp/pro
Hi,
just installed SuSE10.0 a few days ago. The system was runing fine, beside a strange problem with the sound (sound works well if I configure it with alsaconf, if I use YAST xine can't access the 5.1 surround sound). But now, a few days later some strange error arise:
* gimp with started successfully won't start again (memory access error) * firefox is instable, after erasing the .mozilla direcotory in my home it dosn't start anymore: (Gecko:6737): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed /usr/bin/firefox: line 251: 6737 Speicherzugriffsfehler $MOZ_PROGRAM $MOZ_LANG - again memory access error
What I have done after installing SuSE10:
* installed another theme for kdm (you have to write it to /opt/kde3/share/apps/kdm/themes/SUSE) * installed xine, kaffeine and MPlayer from packman (x86_64) * installed transcode, xvid, libfame, speex, libdvdcss, libmpeg3, lame, libpostproc, mjpegtools, w32codec (only for dependencies), a52dec and DVDRip form packman (all x86_64 - only the w32codec not) * installed the aqua theme for IceWM and the aqua-graphite stile from kde-look * doing the online-update
Any ideas what I can do? Or any similar problems? Or any ideas if this is only with amd64?
Thanks, Martin
Hi,
just want to say the problem is solved. It was a problem with the aqua stile for KDE.
Martin
-
Andreas Jaeger -
Martin Schmidt -
Riccardo Ghiglianovich