Dave Vitek <dvitek%grammatech.com@localhost> writes:
Looks like things loaded due to LD_PRELOAD don't search /emul. Here
is a short experiment:
$ echo "int main(){ return 0; }" > nop.c
$ gcc -m32 nop.c -o nop
$ LD_PRELOAD=app/lib64/libhook.so ./nop
app/lib64/libhook.so: unrecognized file format2 [2 != 1]
$ LD_PRELOAD=app/lib/libhook.so ./nop
$ ls /emul/netbsd32/
libhook.so
$ LD_PRELOAD=libhook.so ./nop
Cannot open "libhook.so"
$ gcc -m64 nop.c -o nop
$ LD_PRELOAD=libhook.so ./nop
Cannot open "libhook.so"
It occurs to me that linux emulation processes may have similar challenges.
There is an existing problem report here:
http://gnats.netbsd.org/47509
Relevant code from ld.so_elf confirms that it just does a straight up
open() of the values in the environment variable and doesn't search
anywhere:
So:
You are showing something looking for app/lib/libhook.so, and then
failing to find it as libhook.so. That's not a surprise.
I suggest first using absolute paths for libraries. That's the normal
case and more likely to work.
ld.so doesn't do any searching. The process of looking in
/emul/netbsd32 is built into namei and thus works at the system call
level.
Use ktrace to see what's happening with system calls.