The -ddependencyfield option takes effect for all executables after the option, until the next -ddependencyfield. The default dependencyfield is Depends.
If the same dependency entry (or set of alternatives) appears in more than one of the recognised dependency field names Pre-Depends, Depends, Recommends, Enhances or Suggests then dpkg-shlibdeps will automatically remove the dependency from all fields except the one representing the most important dependencies.
If the library not found is in a private directory of the same package, then you want to add the directory to LD_LIBRARY_PATH. If it's in another binary package being built, you want to make sure that the shlibs/symbols file of this package is already created and that LD_LIBRARY_PATH contains the appropriate directory if it also is in a private directory.
This failure can be caused by a bad or missing shlibs or symbols file in the package of the library. It might also happen if the library is built within the same source package and if the shlibs files has not yet been created (in which case you must fix debian/rules to create the shlibs before calling dpkg-shlibdeps). Bad RPATH can also lead to the library being found under a non-canonical name (example: /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libssl.so.9.8 instead of /usr/lib/libssl.so.0.9.8) that's not associated to any package, dpkg-shlibdeps tries to work around this by trying to fallback on a canonical name (using realpath(3)) but it might not always work. It's always best to clean up the RPATH of the binary to avoid problems.
Calling dpkg-shlibdeps in verbose mode (-v) will provide much more information about where it tried to find the dependency information. This might be useful if you don't understand why it's giving you this error.
This is free software; see the GNU General Public Licence version 2 or later for copying conditions. There is NO WARRANTY.