开发者

Using /etc/ld.so.preload in a multi arch setup

开发者 https://www.devze.com 2023-03-06 02:36 出处:网络
Is there some way to use ld.so.preload and cover both 32bit and 64bit binaries? If I list both the 32bit and 64bit versions of the fault handler in ld.so.preload then the loader always complains that

Is there some way to use ld.so.preload and cover both 32bit and 64bit binaries?

If I list both the 32bit and 64bit versions of the fault handler in ld.so.preload then the loader always complains that one of them fails to preload for whatever command I run. Not exactly earth开发者_如何学JAVA shaking since the error is more a warning but I could certainly do without the printout.

Instead of specifying an absolute path I tried specifying simply "segv_handler.so" in the hopes that the loader would choose the lib in the arch appropriate path (a 32bit version is in /lib and a 64bit version is in /lib64).

Not likely apparently.

Is there a way to setup ld.so.preload to be architecturally aware? Or if not is there some way to turn off the error message?


This works:

  1. put library under /path/lib for 32bit one, and put the 64bit one under /path/lib64 and they should have the same name
  2. put the following line in /etc/ld.so.preload: /path/$LIB/libname.so

$LIB will get the value "lib" (for 32bit) or "lib64" (for 64bit) automatically.


There's no reason to try to use ld.so.preload like this. By default ld is smart enough to know that if you're running a 64bit app to only lookup 64bit libs, and same with 32bit.

Case in point, if you have

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

And you try

gcc -lawesome -o funtime funtime.c

It'll choose whatever the default that gcc wants to build, ld will skip libraries of incorrect bit size for that build.

gcc -m64 -lawesome -o funtime funtime.c will pick the 64bit one

gcc -m32 -lawesome -o funtime funetime.c will pick the 32bit one.

This presumes that /etc/ld.so.conf lists /lib and /lib64 by default..


Sadly, I think the answer might be "Don't do that."

From glibc, elf/rtld.c:

There usually is no ld.so.preload file, it should only be used for emergencies and testing. So the open call etc should usually fail. Using access() on a non-existing file is faster than using open(). So we do this first. If it succeeds we do almost twice the work but this does not matter, since it is not for production use.


You can provide 32 and 64 bit library using special expansion keys in the path name. For instance you can use /lib/$PLATFORM/mylib.so and create /lib/i386/mylib.so and /lib/x86_64/mylib.so. Linked will choose the correct one for your executable.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号