在多拱设置中使用/etc/ld.so.preload

时间:2011-05-13 05:27:04

标签: linux loader sigsegv

有没有办法使用ld.so.preload并覆盖32位和64位二进制文​​件?

如果我在ld.so.preload中列出了故障处理程序的32位和64位版本,那么加载程序总是会抱怨其中一个版本无法为我运行的任何命令预加载。不完全是大地震动,因为错误更像是一个警告,但我当然可以没有打印输出。

我没有指定一个绝对路径,而是试图简单地指定“segv_handler.so”,希望加载器在arch适当的路径中选择lib(32位版本在/ lib中,64位版本在/ lib64中)

显然不太可能。

有没有办法设置ld.so.preload在架构上可识别?或者如果没有,有什么办法可以关闭错误信息吗?

4 个答案:

答案 0 :(得分:4)

这有效:

  1. 将库放在/ path / lib下为32bit,并将64bit放在/ path / lib64下 并且它们应该具有相同的名称
  2. 将以下行放在/etc/ld.so.preload中: /path/$LIB/libname.so
  3. $ LIB将自动获得值“lib”(对于32位)或“lib64”(对于64位)。

答案 1 :(得分:2)

没有理由尝试像这样使用ld.so.preload。默认情况下,ld足够聪明,知道如果你运行的是64位应用程序,只能查找64位的库,而且与32位相同。

例如,如果你有

/lib64/libawesome.so /lib/libawesome.so

你试试

gcc -lawesome -o funtime funtime.c

它将选择gcc想要构建的默认值,ld将跳过该构建的不正确位大小的库。

gcc -m64 -lawesome -o funtime funtime.c将选择64位一个

gcc -m32 -lawesome -o funtime funetime.c将选择32位的。

这假设/etc/ld.so.conf默认列出/ lib和/ lib64 ..

答案 2 :(得分:1)

可悲的是,我认为答案可能是“不要这样做。”

来自glibcelf/rtld.c

  

通常没有ld.so.preload文件,它只应用于紧急情况和测试。因此,公开呼叫等通常应该失败。在不存在的文件上使用access()比使用open()更快。所以我们先做。如果成功,我们几乎完成了两倍的工作,但这并不重要,因为它不适合生产使用。

答案 3 :(得分:1)

您可以使用路径名中的特殊扩展键提供32位和64位库。 例如,您可以使用/lib/$PLATFORM/mylib.so并创建/lib/i386/mylib.so/lib/x86_64/mylib.so。 Linked将为您的可执行文件选择正确的。