Confusing meaning of --no-undefined

[Jan Vroonhof <jan dot vroonhof at insignia dot com>]

[I am not sure that this is a bug, or if so which bit is actually the bug so
I am mailing to this list]

Consider two objects foo.o and bar.so on a linux-* target for various *.

nm --undefined foo.o                                  
bar


nm bar.so  | egrep ' T|U'
000006ec T _fini
00000514 T _init
00000690 T bar
         U notdefinedinbar

and the following link lines

A. gcc foo.o bar.so
  This gives an error about a missing 'notdefinedinbar'. OK
B. gcc --shared foo.o
  Gives no error (default is to allow undefined symbols in shared libraries). OK
C. gcc --share --Wl,--no-undefined foo.o
  Gives an error about missing reference to 'bar'. OK
D. gcc --share --Wl,--no-undefined foo.o bar.so
Behavior 1 (binutils 2.11?):
  This gives an error about a missing 'notdefinedinbar'. i.e. like executables
  it recurses down shared libraries and their dependencies.
Behavior 2 (binutils 2.12 and up?):
  No error. i.e. it only checks for undefined symbols is in the current object being build.

The documentation has not changed at all AFAICS and the wording for
the option does not make clear which behavior is meant. It could be
that "Behavior 2" means that --allow-shlib-undefined has now become
the default, but in that case I haven't found a way of turning it off.

So

1. Is this behavior change intentional?
2. Is there a way to reenable behavior 1, i.e. do full checking as if it was an executable?
  This to ensure that if shared library is dlopened() their won't be any unresolved symbols.

Jan