>>> 此貼的回復 >> 假如glibc2.3.4庫在當前目錄下:/home/firfox/ 安裝包為:firfox gcc -g firfox -llibc2.3.4 -L. 其中-l 指定其找的動態庫,-L指定庫的目錄.
>>> 此貼的回復 >> 可能性不大，除非從源代碼編譯firefox。
>>> 此貼的回復 >> 如果自己寫個腳本，在啟動firefox之前設置一下LD_PRELOAD環境變量呢？
>>> 此貼的回復 >> 這個方法沒想到 >I upgraded my system to Fedora Core 4, and when I try to run an >> application I get >> >> Incorrectly built binary which accesses errno or h_errno directly. >> Needs to be fixed. >> mwrpcss: relocation error: >> /home/luke/Desktop/linux/fpga_82/linux/mfw/lib-linux_optimized/libkernel32.so: >> symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link >> time reference >> >> Is there a NO PAIN way to have 2 versions of glibc running?
No. The absolute name of /lib/ld-linux.so.2 appears in each binary executable program, and ld-linux.so.2 must use its corresponding glibc. So when the operating system performs execve() and gives control to the ELF PT_INTERP, then the required glibc version has been determined.
In order to vary the glibc version, then you must introduce some controlled indirection. You can do this at the filesystem level using chroot, at the shell level by wrapping each binary executable old_program in a script: /path/to/glibc/ld-linux.so.2 --library-path /path/to/glibc:$LD_LIBRARY_PATH \ /new/path/to/old_program "$@" or at the PT_INTERP level by using an indirect runtime loader: http://BitWagon.com/rtldi/rtldi.html
What about using LD_PRELOAD naming the other glibc?
[email protected] wrote:
>> What about using LD_PRELOAD naming the other glibc?
It's too late. During execve() the operating system already chose /lib/ld-linux.so.2. If LD_PRELOAD designates a non-matching libc.so.6, then things might not work. ld-linux and libc [and libm, libdl, ...] must be a matched set.
新聞組為comp.os.linux.development.system， 感覺他說的挺有道理的，哪位朋友試驗過？
