apache+php 64 calling elf32 exe
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 -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
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
participants (3)
-
Andreas Jaeger -
Martin Schmidt -
Riccardo Ghiglianovich