On 64 bit architectures, you can run 32 bit executables and the rtld can trace them, but ldd(1) doesn't know yet how to detect them:

    [/] root@ed-exigent>ldd `which httpd`
    ldd: /usr/local/sbin/httpd: can't read program header
    ldd: /usr/local/sbin/httpd: not a dynamic executable

    But...

    [/] root@ed-exigent>LD_32_TRACE_LOADED_OBJECTS==1 `which httpd`
    libm.so.4 => /lib32//libm.so.4 (0x280c8000)
    libaprutil-1.so.2 => /usr/local/lib/libaprutil-1.so.2 (0x280de000)
    libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x280f2000)
    libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28110000)
    libapr-1.so.2 => /usr/local/lib/libapr-1.so.2 (0x281fd000)
    libcrypt.so.3 => /lib32//libcrypt.so.3 (0x2821d000)
    libpthread.so.2 => not found (0x0)
    libc.so.6 => /lib32//libc.so.6 (0x28235000)
    libpthread.so.2 => /usr/lib32/libpthread.so.2 (0x2830d000)

Added support in ldd(1) for the LD_32_xxx environment variables if
the architecture of the machine is >32 bits. If we ever go to 128
bit architectures this excercise will have to be repeated but thanks
to earlier commits today it will be relative simple.

PR:		bin/124906
Submitted by:	edwin
Approved by:	bde (mentor)
MFC after:	1 week

1 files changed, 6 insertions, 0 deletions

diff --git a/usr.bin/ldd/ldd.1 b/usr.bin/ldd/ldd.1
index 72afb39..fab21eb 100644
--- a/usr.bin/ldd/ldd.1
+++ b/usr.bin/ldd/ldd.1
@@ -64,6 +64,12 @@ option.
 It will print a report of all ELF binaries in the current directory,
 which link against libc.so.6:
 .Dl "find . -type f | xargs -n1 file -F " " | grep ELF | cut -f1 -d' ' | xargs ldd -f '%A %o\en' | grep libc.so.6"
+.Sh BUGS
+On 64 bit architectures, dlopen() cannot open 32 bit dynamic libraries,
+so
+.Nm
+will show the error
+.Qq "unsupported file layout" .
 .Sh SEE ALSO
 .Xr ld 1 ,
 .Xr nm 1 ,