$ ldd /usr/X11R6/bin/xterm
/usr/X11R6/bin/xterm:
/usr/X11R6/bin/xterm: Permission denied
/usr/X11R6/bin/xterm: exit status 1
As you can see, ldd is broken on OpenBSD, so therefore OpenBSD is a terrible OS. I mean, who would break ldd?! A minor problem here is that ldd(1) may execute arbitrary code, and xterm has the set-group-id bit turned on, so may execute arbitrary code as some other user. Anyways, arbitrary code execution is bad, unless you're an attacker pretending to be a confused user who wants to trick root into running ldd on some binary that the attacker has been having weird library issues with.
Security
Be aware that in some circumstances (e.g., where the program
specifies an ELF interpreter other than ld-linux.so), some
versions of ldd may attempt to obtain the dependency information
by attempting to directly execute the program, which may lead to
the execution of whatever code is defined in the program's ELF
interpreter, and perhaps to execution of the program itself.
(Before glibc 2.27, the upstream ldd implementation did this for
example, although most distributions provided a modified version
that did not.)
Thus, you should never employ ldd on an untrusted executable,
since this may result in the execution of arbitrary code. A
safer alternative when dealing with untrusted executables is:
https://www.man7.org/linux/man-pages/man1/ldd.1.html
So one piece of ldd(1) advice might be: don't.
objdump -p `which xterm` | grep NEEDED
readelf -d `which xterm` | grep hare
However, object dumping and ELF reading tools may also have security vulnerabilities (elves are pretty complicated to parse), so maybe only poke at untrusted binaries on an isolated test system, or login as the user in question before having a look at the program they claim to be having trouble with. Also it's really easy to forget that ldd(1) may execute arbitrary code, so you may want to put in an alias that disables it by default (and says what wiki page to read as to why it is disabled) in a shared environment?