str*_*ppi 16 linux 64-bit shared-libraries
早上好,
在64位RedHat盒子上,我们必须编译并运行一个32位应用程序.同时我设法编译了所需的gcc版本(4.0.3)和所有需要的32位运行时库,并将LD_LIBRARY_PATH设置为指向32位版本,但现在在剩余的构建过程中,需要执行一个小的java程序,作为64位程序安装在/ usr/bin中,现在首先找到32位版本的libgcc_s.so.
通常,如果我将LD_LIBRARY_PATH设置为32位版本,我会破坏64位程序,反之亦然.
它应该如何工作?我确信我不是第一个遇到这个问题的人.它通常如何解决?
此致,斯特凡
Dav*_*ner 10
添加两个 32位和64位目录到LD_LIBRARY_PATH.
如果这样做,那么32位或64位的ld.so将使用正确的库.
例如,一个32位测试应用程序"test32"和64位测试应用程序"test",在用户homedir中使用本地安装的(较新版本的)gcc和binutils副本,以避免破坏系统范围的安装GCC:
=> export LD_LIBRARY_PATH=/home/user1/pub/gcc+binutils/lib:/home/user1/pub/gcc+binutils/lib64
=> ldd ./test32
    libstdc++.so.6 => /home/user1/pub/gcc+binutils/lib/libstdc++.so.6 (0x00111000)
    libgcc_s.so.1 => /home/user1/pub/gcc+binutils/lib/libgcc_s.so.1 (0x00221000)
=> ldd ./test
    libstdc++.so.6 => /home/user1/pub/gcc+binutils/lib64/libstdc++.so.6 (0x00007ffff7cfc000)
    libgcc_s.so.1 => /home/user1/pub/gcc+binutils/lib64/libgcc_s.so.1 (0x00007ffff7ad2000)
(删除了不太有趣的库路径)
这表明加载器知道忽略错误架构的库,至少在这个Scientific Linux 6.3(RHEL派生)系统上.我希望其他发行版的工作方式类似,但尚未对此进行测试.
但是,这可能只是比你的(未指定的)发行版版本更新.
作为解决方法,将 Java 调用包装在一个小的 shell 脚本中unset,LD_LIBRARY_PATH然后调用可执行文件。或者,这也可能有效:
LD_LIBRARY_PATH= java...
请注意“=”和可执行文件名称之间的空格。
| 归档时间: | 
 | 
| 查看次数: | 20078 次 | 
| 最近记录: |