I fixed a similar problem in domestic (encrypting) telnet, but telnet
and telnetd currently still suffer the problems you note, IF you have
not installed libraries from /usr/src/domestic/lib into your DESTDIR
tree.

Look at the link line:
cc   -o telnetd -nostdlib -L/usr1/netbsd/build/academic/obj.alpha/build/usr/lib /usr1/netbsd/build/academic/obj.alpha/build/usr/lib/crt0.o /usr1/netbsd/build/academic/obj.alpha/build/usr/lib/crtbegin.o authenc.o global.o slc.o state.o sys_term.o telnetd.o termstat.o utility.o -L/usr1/netbsd/co/academic/src/domestic/libexec/telnetd/../../lib/libtelnet/obj.alpha -L/usr1/netbsd/co/academic/src/domestic/libexec/telnetd/../../lib/libkrb/obj.alpha -L/usr1/netbsd/co/academic/src/domestic/libexec/telnetd/../../lib/libdes/obj.alpha -lutil -ltermcap -ltelnet -lkrb -ldes -lcrypt -lgcc -lc -lgcc /usr1/netbsd/build/academic/obj.alpha/build/usr/lib/crtend.o

The -L$(DESTDIR)/usr/lib comes at the _front_ and blows out the attempts
to use -L$(relative-path-to-domestic-libtelnet) later in the link line.

Any suggestions for how to fix this build rule to use the "nearby" copy
of libtelnet even when $(DESTDIR) is set?

==John