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.
Attachment:
pgpqHjXy6BCG7.pgp
Description: PGP signature